-------------------------
-  HARDWARE  MAME 0.131 -
-------------------------

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 / MCS-48
  6.3   I8041
  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  i860XR
  6.16  i960KB
  6.17  PENTIUM
  6.18  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
  7.9   TMS57002

  8.    Hitachi
  8.1   HD6309
  8.2   M6803
  8.3   HD63701
  8.31  HD63705
  8.4   HD64180
  8.5   H8/3xx
  8.51  H8/320
  8.52  H8/325
  8.53  H8/3002
  8.54  H8/3007
  8.55  H8/3044
  8.56  H8/3334
  8.57  H8/3337
  8.58  H8/3344
  8.6   Z180
  8.7   FD1089
  8.8   FD1094
  8.9   FD1149
  8.A   SH-1
  8.B   SH-2 / SH7600 family
  8.C   SH-4

  9.    NEC
  9.1   D70008
  9.2   uPD7751 / N7751
  9.3   uPD780C
  9.4   MC8123
  9.5   uPD7807
  9.6   uPD7807
  9.7   uPD7810
  9.8   NEC Vxx
  9.81  V20
  9.82  V30
  9.83  V30MZ
  9.84  D80000
  9.85  DYNA CPU91A
  9.86  NANAO 08J27291
  9.87  V33
  9.88  V53
  9.89  V60
  9.8A  V70
  9.8B  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   DSP-2
 11.6   RSP
 11.7   RCP
 11.8   RDP
 11.9   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-900
 13.61  TLCS-90
 13.62  TMP90841
 13.63  TMP91C640

 14.    Konami
 14.1   Konami 1
 14.2   KONAMI

 15.    MIPS CPUs
 15.1   R3000
 15.11  R3560
 15.2   R4300
 15.21  R4310
 15.3   R4600
 15.31  IDT R4650 (little)
 15.32  IDT R4650 (big)
 15.4   R4700
 15.5   R5000
 15.6   RM7000
 15.8   QED5271
 15.9   PSX CPU
 15.91  CXD8661R

 16.    AMD
 16.1   AMD 2901
 16.2   AM29000
 16.3   AM29116 / Real Time Image Processor
 16.4   AM29323
 16.5   CUBEQCPU

 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  PowerPC 602
 19.14  PowerPC 603e/R
 19.15  PowerPC 403GCX
 19.16  PowerPC MPC8240
 19.17  Konami PowerPC based 3D games
 19.2   PowerPC dynamic recompiler
 19.3   DRC - Dynamic Re-Compiling
 19.31  x86/x64
 19.4   PowerPC MMU
 19.5   PowerPC FPU

 20.    SE3208

 21.    Others
 21.1   APEXC
 21.2   GenSync
 21.3   CP1610
 21.31  SSP1601
 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
 21.K   Sharp LR35902

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

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



0.    MAME CPU Interface

- 0.130u2            : CPU cores are now enabled on a per CPU core family basis instead of per CPU core variant. As a result CPUDEFS is no longer needed in the makefile [Wilbert Pol].
- 0.130u1            : Aaron Giles changed the CPU cores to use the get_safe_token() pattern like other devices.
- 0.129u4            : Aaron Giles fixed disassembler for CPUs with address bus shifts. Nathan Woods added the ability to invoke CPU input lines with devcb callbacks.
- 0.129u1            : Dirk Best removed several useless occurrences of "#define INLINE" in CPU and sound cores.
- 0.129              : Significantly optimized the inner execution loop. Arkanoid 2 is ~2.5x faster with maximum interleave now. [Aaron Giles] CPU interface organization shuffle. The file cpuintrf.h now merely describes the interface, but does not contain any implementation. All remaining bits of implementation have been migrated either to cpuexec.c or to debugcpu.c. Specifically, cpu_dasm() is now debug_cpu_disassemble(), and cpu_set_dasm_override() is now debug_cpu_set_dasm_override(). Also moved memory_address_physical() to debug_cpu_translate(), since it was only ever used for debugging [Aaron Giles]. Aaron Giles changed all CPU and sound cores to use memory_find_address_space() instead of cpu_get_address_space(). The former is reliable even during early initialization when the CPU cores generally need it. Aaron Giles removed the dummy CPU core and cpuintrf.c. Aaron Giles changed the core execution loop to directly call the execute function instead of using the inline helper (which has been removed). Aaron Giles normalized the CPU cores to always do while (icount > 0), in order to remove the kludge in cpuexec.c that caused us to overeat by 1 cycle to accommodate those cores that there looping while (icount >= 0). Aaron Giles cleaned up the profiler. Reduced its runtime overhead significantly by inlining the check to see if it is running. Removed obsolete entries and updated the text to more accurately describe each one. Added CPU tags to the CPU names. Switched to using an astring for building the final string. Unfortunately, still a bit too much overhead to leave it on in all builds.
- 0.128u7            : Made CPUs into proper devices. CPUs are now added in the machine configuration just as any other device, and the standard CPU configuration is performed via the inline configuration macros [Aaron Giles]. Aaron Giles and Atari Ace changed cpu_type from an enumeration into a pointer to the CPU's get_info function, very similar to device behavior. Updated all drivers to #include the necessary header files for the CPU's they reference. Aaron Giles added function cpu_get_type() to return the CPU type. Aaron Giles changed several cpu_* functions over to the device_* equivalents, specifically for get/set info and for reset. Aaron Giles cleaned up code that looped over CPUs via the machine->cpu array to now loop using the type-based device list. Aaron Giles cleaned up the generic interrupt_enable code to work with CPU devices instead of numbers. Aaron Giles removed cpuintrf_init() which is no longer necessary. Aaron Giles defined a generic device execute function callback, though it is not used yet. The long term plan is that any device with an execute callback will be scheduled along with the CPUs. Now that CPUs are devices, their scheduling will be moved over to this logic eventually. Aaron Giles moved device startup to *before* the DRIVER_INIT is called. This is to allow the DRIVER_INIT to configure devices that have been properly allocated. So far I don't see any negative effects, but be on the lookout if something weird shows up. Aaron Giles rewrote the device iteration logic to make use of the typenext field and the newly-introduced classnext field for iterating more efficiently through devices of a given type or class. Aaron Giles cleaned up many other CPU headers to move memory read/write macros out of them, since they are inappropriate and should be prive to the CPU core. Aaron Giles added the concept of a cpu_state_table, which is supplied by the CPU cores and which describes all the register state accessible to the debugger and other subsystems. The format of the table is such that most data can be simply fetched from memory without the further involvement of the CPU core, including the display of common formats. Extensibility points are available for custom display and for importing/exporting the data to intermediate variables for more complicated scenarios. Updated the ADSP21xx, TMS340x0, i86, Z80, Z180 and 8085 cores to use this. More cleanup [Aaron Giles]: Added address-space-specific constants for the various bus width and shift CPU interface constants. Changed all the cores to use them. Aaron Giles added new MDRV_QUANTUM_PERFECT_CPU(x) to specify that the minimum quantum should be enough to ensure that the specified CPU tag only ever executes a single instruction at a time. This can be used to explicitly require "perfect" synchronization for drivers that have multiple CPUs with shared memory. Turned this on for the arknoid2 driver for now as a test (the interleave on that driver was already very close to perfect anyway).
- 0.128u6            : Aaron Giles enabled all CPU cores/variants. Fixed compile issue revealed as a result. Aaron Giles added new function cpuexec_describe_context(machine) which can be used in logerror() and other printf-style functions to return a description of the current CPU/PC given only the machine. Changed several dozen sites to use this instead of directly interrogating the activecpu. Aaron Giles removed all other uses of activecpu throughout the system. Removed activecpu from the machine structure to prevent future abuse. Aaron Giles removed cpu_push_context() and cpu_pop_context(), and all call sites. Aaron Giles removed get context/set context calls from the CPU interface entirely. Aaron Giles removed safe_cpu_get_pc() which doesn't really make sense anymore. Aaron Giles moved cpu_execute() to be an inline function. Atari Ace removed remaining deprecat.h references from the CPU cores. Aaron Giles expanded cpuexec cycles <-> attotime functions to handle UINT64s.
- 0.128u5            : Aaron Giles removed globals from cpuexec. Also removed ATTOTIME_TO_CYCLES() and ATTOTIME_IN_CYCLES(). Replaced them with functions in cpuexec: cpu_clocks_to_attotime() and cpu_attotime_to_clocks(), both of which take CPU devices instead of indexes. Updated all callers, many of which were using the functions dubiously. Aaron Giles removed cpunum_get_active() calls and activecpu references from all of the CPU cores. Normalized several local CPU state variables to the generic 'cpustate' instead of names_with_underscores. Removed all references to cpunum_get_active() and removed the function entirely [Aaron Giles, Andrew Gardner]. Aaron Giles renamed constants CPU_IS_LE -> ENDIANNESS_LITTLE and CPU_IS_BE -> ENDIANNESS_BIG. Aaron Giles added a number of new cputag_* macros to cpuexec.h. Aaron Giles renumbered CPU and sound get/set info constants to align with the device constants, and shared values where they were perfectly aligned. Aaron Giles set the type field in the fake device_configs for CPU and sound chips to a get_info stub which calls through to the CPU and sound specific get_info functions. This means the device_get_info() functions work for CPU and sound cores, even in their fake state. Aaron Giles changed device information getters from device_info() to device_get_info() to match the CPU and sound macros. Aaron Giles removed cpunum_get_active(). Main important change is that IDE controllers with bus mastering (DMA) need to specify the target address space in the IDE device configuration. Aaron Giles removed mame_find_cpu_index(). Use cputag_get_cpu() instead. Updated all drivers calling this to the newer function, and generally simplified their code as a result. Aaron Giles removed mostly silly uses of activecpu from the CPU cores. 
- 27th November  2008: MAME 0.128u4 Changes [Aaron Giles]: A number of people have asked about the changes that went into MAME 0.128u4, and why they were made. This article explains the motivation and reasoning behind these changes, and what still needs to be done. CPU Context Switching: When MAME was originally designed, wasn't envisioned that it would eventually be used to emulate multiple CPUs at the same time. MAME 0.1 was derived from Nicola's Multi-Pac emulator, which emulates Pac-Man based hardware, which consists simply of a single Z80 CPU. Eventually, more arcade games were discovered to run on similar hardware, and a large collection of Z80-based games were quickly supported. Of course it was soon discovered that arcade hardware is much more diverse than a single Z80. Support for additional 8-bit CPUs was added, including the 6502 and 6809. In addition, it quickly became apparent that many games had more than one CPU, so support for multiple CPUs was added. The problem is, the code in the CPU emulators for the various CPUs was not designed to run multiple instances of the same type of CPU, and so in order to make this work, a concept called context switching was introduced. Let's take the Z80 as our example. The main problem with running more than one Z80 CPU at a time is that the Z80 CPU emulator stored the state of the CPU in global variables. At the time (remember this is back in the days of the 386 and DOS), it was faster to fetch data from global variables than to allocate memory for each Z80 and reference all the CPU state via a pointer. So in order to allow the Z80 core to continue to work the way it did, we introduced context switching. With context switching, when MAME needs to stop executing one of the Z80's and begin executing one of the others, it asks the first Z80 to copy all of its relevant global variables to some temporary memory, and then copy the second Z80's state from temporary memory back into the global variables. At this point, the global variables contained the state of the second Z80, and it could be executed normally. In practice, this worked great because MAME would execute the first Z80 for many thousands of cycles, perform a context switch, execute the second Z80 for many thousands of cycles, perform a context switch, etc., so the context switch did not require a significant percentage of the total execution time, because it was only done once every few thousand emulated cycles. Where the problems arise is when we want to do "cycle accurate" execution of these two Z80's. In this case, we really want to run each Z80 for just one or two cycles at a time, and switch back and forth between them many many times per second. When we do this, we execute the first Z80 for a cycle or two, context switch, execute the second Z80 for a cycle or two, switch again, etc. In this situation, it turns out, we spend more time context switching than we do executing. The solution to this is to get rid of the context switching. To do this, we need to allocate memory for each Z80 and instruct each Z80 to reference all of its data from that memory, rather than accessing global variables. In the past, doing this was a bit of a performance penalty, but on modern processors and modern compliers, it is either a wash or marginally faster to do it the "right" way. So one of the major motivations of the changes in MAME 0.128u4 is to make changes that get rid of the CPU context switching. To do this, the interfaces to all the CPU cores had to change, and each core has to be modified to fetch its state from memory pointers instead of global variables. As of the 0.128u4 release, several important CPU cores have been converted, but more work is still pending in this direction. Memory Context Switching: In addition to the way the CPUs do context switching, the memory system in MAME also did the same thing. That is, when a CPU needs to read or write to memory, it works with the memory system to figure out whom to call to implement to read/write behavior. Whenever MAME needed to stop executing of one CPU and begin execution of another, it had to perform a memory context switch, so that memory accesses from the new CPU accessed the correct memory. In order to remove memory context switching, the state of the memory subsystem needed to be moved out of global variables and into allocated memory. The problem is that the memory system wasn't really organized in this manner, so some significant changes had to be made. In the end, I decided to expose the concept of an "address space" to describe the state of the memory subsystem. Each CPU can have one or more address spaces, and whenever the CPU needs to talk to the memory system, it hands a pointer to the relevant address space to the memory system so that the memory system knows how to map that memory access. In addition, when the memory system identifies a particular callback in a game driver to handle a read or a write, it also passes along the pointer to the address space structure, so that the game driver has the information it needs to know about handling that memory access.To make all this work, the interfaces to all the read/write handlers in the system had to change, the memory system had to be rewired, and all the CPU cores had to be modified to pass along these address space objects. As of 0.128u4, the memory context switch has been removed entirely. Completing this work is necessary before we can eliminate the CPU context switching. The "Active" CPU: One of the things that goes hand-in-hand with context switching is the notion of an "active" CPU, which is defined to be the CPU whose context is currently copied into the global variables. As we remove the need for CPU context switching, the notion of an active CPU becomes less well-defined and less meaningful. Take, for example, a CPU (we'll call it CPU A) which can write to the memory space of another CPU (call it CPU B). In a context switching system, when CPU A is executing, CPU A's state is loaded into the global variables, and all of CPU A's memory reads and writes use the global memory state information in order to know what happens when memory is accessed. Logically, CPU A is the "active" CPU. Now let's say CPU A performs some action which causes it to modify CPU B's memory space. In order to do this, we must save off CPU A's state (both CPU and memory state), and load up CPU B's state, thus making CPU B the "active" CPU. Then we perform the access to CPU B's memory space. When finished, we save off CPU B's state and restore CPU A's state so that it can continue executing. In a more modern system, when CPU A is executing, CPU A's state lives off in memory somewhere and can be accessed at any time, and its address spaces are similarly configured so that they can be accessed at any time without context switching. Now CPU A performs the same action which causes it to modify CPU B's memory space. In this case, we don't need to do any context switching. Instead, CPU A can directly modify CPU B's memory space by passing in a pointer to CPU B's address space when it performs its memory operations. It should be obvious that the big difference in these two scenarios is that there is no context switching in the second case, which should make things faster. But even more importantly, there is no "active" CPU at any point in the second case. One could argue that because CPU A is executing, that it should be designated "active"; however, even in this case, CPU B is certainly never considered active, even though it previously would have been. Looking further down the line, if we define a CPU as "active" while it is executing, we consign ourselves to only ever executing a single CPU at a time, because only one CPU can ever be "active" at a time. Thus, the right solution is to get rid of this "active" CPU notion. Unfortunately, the MAME drivers and core are peppered with references to the active CPU. These must go over time. Only when they are gone can we fully remove the context switching; as long as references to the active CPU still exist, we have to continue to context switch in order to keep up a valid definition of the active CPU.
                       What Does This All Mean? For users, all the existing games should continue to work. Speed should be equivalent if not a bit better, especially in situations where there is aggressive context switching today. Once all the context switching is removed, MAME will be doing less work when it switches frequently between different CPUs. Longer term, however, it is likely that some of these cases will get slower again, because for many early games, the multiple CPUs work closely in concert, and to achieve the most accurate behavior, we ideally should execute each CPU one instruction at a time, alternating back and forth very quickly. Today, this makes performance very bad; with the context switching changes in, I hope it will be bearable at least for many of the 8-bit systems. For developers, these changes mean that MAME is more object-oriented. Even though MAME is written in straight C and not C++, you can imagine that core structures in the system such as running_machine, device_config, and address_space are objects, and pointers to these objects are passed in and out of most calls in the system. There should be very few if any cases where the need for an "active" CPU is necessary any more, and references to the global Machine (capital "M") object are removed in favor of pointers to that machine that are passed into your functions. The changes we are making aren't particularly revolutionary from a software architecture point of view, but they are revolutionary from a MAME design point of view. There are still many more changes to come as we push toward removing the CPU context switching altogether, but as of MAME 0.128u4 the core infrastructure is in place to make these changes happen. This particular update was the "biggie"; future updates along this path should be smaller until we are in a position to finally remove the CPU context switch for good.
- 0.128u4            : Removed emu\cpuint.c/h. Aaron Giles converted remaining CPU cores over to new memory functions. Major cpuintrf changes [Aaron Giles]: Added a set of cpu_* calls which accept a CPU device object; these are now the preferred means of manipulating a CPU. Removed the cpunum_* calls; added an array of cpu[] to the running_machine object; converted all existing cpunum_* calls to cpu_* calls, pulling the CPU device object from the new array in the running_machine. Removed the activecpu_* calls; added an activecpu member to the running_machine object; converted all existing activecpu_* calls to cpu_* calls, pulling the active CPU device object from the running_machine. Changed cpuintrf_push_context() to cpu_push_context(), taking a CPU object pointer; changed cpuintrf_pop_context() to cpu_pop_context(); eventually these will go away. Many other similar changes moving toward a model where all CPU references are done by the CPU object and not by index. Added CPU device parameters to all CPU callbacks except for the context ones (which are going away), and the validity check. Populated tag and static_config parts of fake CPU device. Removed 'config' parameter from CPU_INIT. Modified CPU cores to pull config from the device static_config. Massive API cleanup/change [Aaron Giles]: The primary goal is that all CPU-related APIs now take a device pointer instead of an index. All functions that take a CPU device are prefixed with cpu_*. All functions that are globally related to cpu execution are prefixed with cpuexec_*. Below is a list of some of the mappings: cpu_boost_interleave -> cpuexec_boost_interleave, cpunum_suspend -> cpu_suspend, cpunum_resume -> cpu_resume, cpunum_is_suspended -> cpu_is_suspended, cpunum_get_clock -> cpu_get_clock, cpunum_set_clock -> cpu_set_clock, cpunum_get_clockscale -> cpu_get_clockscale, cpunum_set_clockscale -> cpu_set_clockscale, cpunum_get_localtime -> cpu_get_local_time, cpunum_gettotalcycles -> cpu_get_total_cycles, activecpu_eat_cycles -> cpu_eat_cycles, activecpu_adjust_icount -> cpu_adjust_icount, cpu_trigger -> cpuexec_trigger, cpu_triggertime -> cpuexec_triggertime, cpunum_set_input_line -> cpu_set_input_line and cpunum_set_irq_callback -> cpu_set_irq_callback. In addition, a number of functions retain the same name but now require a specific CPU parameter to be passed in: cpu_yield, cpu_spin, cpu_spinuntil_time, cpu_spinuntil_int, cpu_spinuntil_trigger and cpu_triggerint. Merged cpuint.c into cpuexec.c. One side-effect of this change is that driver reset callbacks are called AFTER the CPUs and devices are reset. This means that if you make changes to the CPU state and expect the reset vectors to recognize the changes in your reset routine, you will need to manually reset the CPU after making the change (since it has already been reset). Added a number of inline helper functions to cpuintrf.h for managing addresses. Removed cpu_gettotalcpu(). This information is rarely needed outside of the core and can be obtained by looking at the machine->cpu[] array. Changed CPU interrupt acknowledge callbacks to pass a CPU device instead of machine/cpunum pair. Changed VBLANK and periodic timer callbacks to pass a CPU device instead of machine/cpunum pair. Renamed all information getters from cpu_* to cpu_get_* and from cputype_* to cputype_get_*.
- 0.128u3            : Aaron Giles defined macros for all core CPU functions, along with macros for the name and for calling, in the spirit of the devintrf.h macros. Aaron Giles changed the CPU IRQ callbacks to a proper type, and added a device parameter to them. Aaron Giles added machine parameter to cpu_boost_interleave. Aaron Giles updated cpuexec to compute the "perfect" interleave value taking into account the minimum number of cycles per instruction specified by the CPU core. Updated Z80 core to indicate that the minimum cpi is 2. Fixed incorrect minimum cpi in the 68020+ cores. Atari Ace added ADDRESS_MAP_NAME macro, updated CPU cores to use it to reference internal address maps.
- 0.127u8            : Couriersud fixed assertion in cpuint.c.
- 0.127u7            : Aaron Giles fixed various games with: CPU x: PULSE_LINE used with level-detected IRQ y.
- 0.127u4            : CPU-internal regions now have priority again. Fixed mario by installing a handler in the sound_start function [Aaron Giles].
- 0.127u3            : Aaron Giles fixed memory handling of internal banks. They should be LOWER priority than the driver's memory maps. Reverted recent changes to MCS-48 core that were very hacky and which crashed many games. You can now properly override the internal memory map and do your own banking. CPUs, sound chips, devices and ROM-regions which are specified by devices now have their tags auto-prefixed with the device's tag. This allows for multiple instances to be present. For example, the PR-8210 laserdisc player has a CPU with a tag of "pr8210". When it is included as a device by a driver, the driver may tag the device "laserdisc". The resulting final CPU tag name will be "laserdisc:pr8210". Also updated the debugger expression engine to support names with embedded colons [Aaron Giles]. Aaron Giles added checks to ensure that tags used for CPUs, sound chips, regions, and devices follow some basic rules: they should be less than 15 characters long, be all lower-case, and only contain letters, numbers, underscores, or dots (no spaces). This is to ensure that they can be used properly in debugger expressions and don't get too long or unwieldy to type (even 15 chars is rather long). Fixed up all tags in the system that failed these checks.
- 0.126u5            : Derrick Renaud updated structure and naming conventions of sound and CPU cores to match core conventions.
- 0.126u4            : Aaron Giles added new functions cputag_set_input_line() to assert input lines via CPU tag instead of index.
- 0.126u3            : Aaron Giles changed the auto-binding behavior of CPU regions. Previously, the first CPU would auto-bind to REGION_CPU1 (that is, any ROM references would automatically assume that they lived in the corresponding region). Now, each CPU automatically binds to the region with the same tag as the CPU itself. This behavior required ensuring that all previous REGION_CPU* regions were changed to regions with the same tag as the CPU.
- 0.126u2            : Aaron Giles changed MDRV_CPU_ADD to require a tag. Removed MDRV_CPU_ADD_TAG. Tagged all CPUs.
- 0.125u9            : Aaron Giles removed calls to memory_set_context() in favor of cpuintrf_push_context().
- 0.125u3            : Nicola Salmoria fixed cpu_getiloops() which was not returning the correct value. Aaron Giles changed the behavior of the translate callback in the CPU interface: Added new 'intention' parameter to the translate callback to indicate read/write/fetch access, user/supervisor mode, and a flag for debugging. Updated all call sites to pass an appropriate value. Updated all CPU cores to the new prototype.
- 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 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.
- 0.10               : Added cpuintrf.c/h.



1.    Zilog

1.1   Z80

- 0.130u4            : Aaron Giles corrected System 1 Z80 clocking: Each opcode fetch is 2 cycles with /M1 low, so each byte of opcode fetching causes slightly longer delays than the previous tables. Implemented approximate wait state timing for videoram access; further accuracy will rely on getting a dump of the PAL16R4 that controls the horizontal video timing.
- 0.130u3            : Aaron Giles changed Z80 cycle table definitions to be per-device. Removed old set_info constants for the tables; they are now set up via the z80_set_cycle_tables function.
- 0.130u1            : Z80PIO: When outputting from a port to the hardware in PIO mode 3, only those bits defined by the mask should be output. MAME currently outputs everything [Robbbert].
- 0.129u6            : Another round of static/const qualifier additions, plus a rename of has_addon_chip to snes_has_addon_chip.  Notably a number of z80ctc_interface are now const (devicification must have removed the cases where it was dynamically modified) [Atari Ace].
- 0.128u7            : Aaron Giles added the concept of a cpu_state_table, which is supplied by the CPU cores and which describes all the register state accessible to the debugger and other subsystems. The format of the table is such that most data can be simply fetched from memory without the further involvement of the CPU core, including the display of common formats. Extensibility points are available for custom display and for importing/exporting the data to intermediate variables for more complicated scenarios. Updated the Z80 core to use this.
- 0.128u5            : Curt Coder added placeholders for interrupt callback and Z80 daisy chain functions in Z80DMA.
- 0.128u4            : Aaron Giles cleaned up macro mess in the Z80 core. Switched to using generic memory calls instead of program_* and io_*.
- 0.128u3            : Miodrag Milanovic added support for recently-discovered internal Z80 register to the Z80 core. Improves accuracy of undefined flags. Aaron Giles converted the Z80 core to reference their data via pointers instead of global structs, in anticipation of future changes. Aaron Giles updated cpuexec to compute the "perfect" interleave value taking into account the minimum number of cycles per instruction specified by the CPU core. Updated Z80 core to indicate that the minimum cpi is 2.
- 0.127u7            : Aaron Giles made the Z80 daisy chain aware of referencing device-specific devices. Aaron Giles added new functions for building device-relative tags. Changed machine configuration builder to use these functions. Also changed the laserdisc player devices to use them. Updated Z80 CTC/SIO code to assume that the CPU provided for the clock is relative to the device that the CTC/SIO belong to. Updated memory code to assume that regions and devices referenced by the memory map are relative to the device the associated CPU belongs to.
- 0.127u6            : Wilbert Pol converted the Z80PIO implementation into a device. Aaron Giles converted Z80 CTC to a proper device. Updated all drivers. Added new item to the interface which is the tag of a CPU to take the base clock from. Aaron Giles changed Z80 daisy chain interface to simply be a list of devices in the chain. Interrupt callback functions are now fetched via the standard device interface and referenced by the daisy chain code. Aaron Giles changed Z80 PIO interrupt callback to pass a device instead of the machine. All device callbacks should provide the device. Aaron Giles converted Z80 SIO to device. Updated drivers accordingly.
- 0.126u4            : Z80DMA device now require device callback handlers instead of machine handlers. Updated affected drivers accordingly [Couriersud].
- 0.125u7            : Cleaned up Z80DMA interface [Couriersud]: Removed compatibility to old Z80DMA driver. Now uses std. callbacks (READ8_HANDLER, WRITE8_HANDLER). Updated mario and dkong3 accordingly.
- 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.
- 0.37b7             : Removed cpu\z80\makez80.c.
- 29th July      2000: Juergen Buchmueller fixed the Z80 problems in Brute Force.
-  9th May       2000: Juergen Buchmueller fixed some Z80 core bugs.
- 0.36RC1            : Removed cpu\z80\z80_vm.c/h.
-  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             : Added cpu\z80\z80_vm.c. 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.
- 0.35b11            : Added cpu\z80\z80_vm.h.
- 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.
- 27th February  1999: Jürgen has made the Z80 code faster with memory accesses.
- 0.35b3             : Added cpu\z80\makez80.c. [DOS] X86 asm Z80 core [Juergen Buchmueller].
- 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.35b2             : Removed z80\asm.bat.
- 0.35b1             : Added z80\asm.bat. Removed z80\z80codes.h, z80debug.c, z80io.h, z80cdx86.h, makefile and readme.txt. 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.30               : Removed z80\z80.txt.
- 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               : Added machine\z80fmly.c/h. 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               : Changed daa.h to z80\z80daa.h. 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               : Added z80\z80.c/h, z80codes.h, z80dasm.c/h, z80debug.c, z80io.h, z80cdx86.h and daa.h. 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

      KL5C80   Nintendo Z80 baed CPU (hng64.c)


- 0.120              : Andrew Gardner and Justin Kerk hooked up the KL5C80 communications CPU to the HNG64 BIOS and emulated some of its features.
- 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.128u6            : Updated Z8000 tables to reflect recent findings [Juergen Buchmueller]. Pointer-ified the Z8000 core [Aaron Giles].
- 0.109u5            : Aaron Giles converted the z8000 disassemblers to the new format and added step in/out support where it was obvious.
- 0.35b2             : Added z8000\z8000.c/h, z8000cpu.h, z8000dab.h, z8000ops.c, z8000tbl.c, 8000dasm.c and makedab.c. 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.129              : Aaron Giles added kludge to 6502 core such that CLI followed by RTI does not allow any interrupts through. In the future, the 6502 interrupt handling needs further revisiting.
- 0.128u3            : Couriersud converted the M6502 core to reference data via pointers.
- 0.128u2            : Pugsy synchronized 6502 disassembly with CPU core.
- 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.
- 0.37b3             : Added cpu\m6502\ops4510.h and m6502.txt.
- 0.37b2             : Added cpu\m6502\opsc02.h and ill02.h.
- 0.36RC1            : Changed m6502\m6502ops.h and tbl6502.c to t6502.c, ops02.h.
- 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].
- 0.34b4             : Removed m6502\codes.h, makefile, dasm.c and tables.h.
- 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             : Added m6502\m6502ops.h, tbl6502.c, tbl6510.c and tbl65c02.c. 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               : Added m6502\6502dasm.c. Removed m6502\debug.c and m6502.txt. 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               : Added m6502\m6502.c/h, codes.h, tables.h, dasm.c, debug.c and makefile. 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.128u1            : Phill Harvey-Smith fixed a subtle bug in the 65c02 emulation where the result of the BIT instruction differs on the 65c02 (from the 6502), when executed in immediate mode.
- 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.36RC1            : Added t65c02.c.
- 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.125u7            : Atari Ace fixed a few build problems with the M65CE02 CPU core.
- 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            : Changed cpu\m6502\tbl65c02.c to m65ce02.c/h, t65ce02.c, t65sc02.c and opsce02.h. Added 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.
- 0.36RC2            : Added cpu\m6502\m6509.c/h, t6509.c and ops09.h.
- SOURCE: cpu\m6502\m6509.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.
- 0.36RC1            : Changed cpu\m6502\tbl6510.c to t6510.c.

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


2.16  M4510

- 0.127u1            : M4510 core fixes [Robiza]: Banking in read and write operations. jsr and jsrx instruction. Fixed TSY instruction.
- 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.
- 0.37b3             : Added cpu\m6502\m4510.c/h.
- 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.128u4            : Pointer-ified the 6800 CPU core [Couriersud]: Temporarily named the state var m68_state in the 68xx cores. Reorganized some code for simpler comparison of 68xx cores.
- 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.35b7             : Added cpu\m6800\m6800.c/h, 6800dasm.c and 6800ops.c
- 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.128u6            : Pointer-ified the M6805 CPU core [Andrew Gardner].
- 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               : Added m6805\m6805.c/h, 6805ops.c and 6805dasm.c. 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.35b10            : Removed cpu\m6800\make6808.c.
- 0.35b7             : Added make6808.c. Removed cpu\m6808\m6808.c/h, 6808dasm.c, 6808ops.c and make6808.c.
- 0.35b3             : Brad Oliver fixed a couple of bugs in the 6808 core.
- 0.33b7             : Added m6808\make6808.c. 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               : Added m6808\6808ops.c. 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.
- 0.30               : Added m6808\6808dasm.c. Removed m6808\m6502.txt.
- 0.29               : Added m6808\m6808.c/h. 
- GAMES: Williams - Defender (1980), Stargate (1981), Robotron (1982), Blaster (1983), Joust2 (1986)



3.5   M6809

- 0.128u4            : Pointer-ified the 6809 CPU core [Couriersud]: Temporarily named the state var m68_state in the 68xx cores. Reorganized some code for simpler comparison of 68xx cores. Nicola Salmoria added M6809 config option to control where opcodes 10 and 11 fetch the second byte and changed 6809 disassembler to work with Kram (encrypted). Switched M6809 to new memory functions [Couriersud]: Cleaned up some macros. Aligned code a bit more. Interrupts now checked in cpu_execute instead of set_context.
- 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.
- 0.35b6             : Added cpu\m6809\6809tbl.c.
-  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.30               : Added m6809\6809dasm.c. Removed m6809\m6809.txt.
- 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               : Added m6809\6809ops.c. 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.27               : Removed machine\wac.c.
- 0.24               : Added machine\wac.c.
- 0.23               : Modifications were done to M6809 emulator to support FIRQ.
- 0.21               : Added m6809\m6809.c/h and copying. 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

- 0.129              : Aaron Giles converted 68000 core to use state tables and cleaned up cycle handling in the 68k core.
- 0.128u4            : Removed cpu\m68000\m68k.h and m68kmame.c/h. Significantly pared down the 68k core [Aaron Giles]: Merged outer MAME shell into the core proper and removed unused macros. Changed all external interfaces to pass the CPU device. Enabled 64-bit operations by default. Re-derived the interface functions to cascade and share code more aggressively. These changes also seem to have cured the taito_f3 issues as far as I can tell (at least pbobble3 seems right now). Disentangled the 68000 core [Aaron Giles]: Converting it to be much simpler and less overly abstracted. Hard-coded it for the options that are relevant and never going to change. Removed old unused CPS2 encryption junk. Changed encryption interfaces to pass the CPU core object. Switched M68000 to new memory functions [Couriersud].
- 0.128u3            : Removed cpu\m68000\m68kconf.h. Aaron Giles began the process of pruning options from the 68000 core, hard-coding it for MAME's needs. We've hacked on it sufficiently that it is no longer generic, so this is a good opportunity to simplify the code so that it can actually be followed (still in progress). Aaron Giles converted the M680x0 cores to reference their data via pointers instead of global structs, in anticipation of future changes.
- 0.127u7            : Aaron Giles fixed a number of regressions due to recent 68000 IRQ changes.
- 0.127u6            : Aaron Giles changed 68000 interrupts to only trigger during execution. This means that multiple changes without any execution will be seen as atomic. It also means that PULSE_LINE no longer works for signalling IRQs.
- 0.127u1            : Olivier Galibert changed 68000 IRQ support so that the IRQ lines explicitly simulate a standard demux chip connected to the IRQ lines. This means that the sequence: cpunum_set_input_line(5, ASSERT_LINE); cpunum_set_input_line(3, ASSERT_LINE); and cpunum_set_input_line(3, CLEAR_LINE) now works as expected. This required fixes to several Atari and other drivers. Small optimization to memory handling for 68000 core [Christophe Jaillet].
- 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.
- 0.37b5             : Added cpu\m68000\m68kdasm.c. Removed cpu\m68000\d68k.c/h and d68kconf.h.
- 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            : Added cpu\m6800\6800tbl.c. 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            : Added cpu\m68000\m68k_in.c. Removed cpu\m68000\m68kops.c/h, m68kopnz.c, m68kopac.c, m68kopdm.c and readcpu.h. 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)
- 0.35b9             : Removed cpu\m68000\m68k_in.c.
- 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'. Removed cpu\m68000\cycletbl.h. 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.
- 0.35b7             : Removed cpu\m68000\d68000.h.
- 0.35b6             : Removed cpu\m68000\m68000.c and d68000.c.
- 0.35b5             : Added m68000\m68kcpu.c/h, m68kmake.c, m68kopac.c, m68kopdm.c, m68kopnz.c, m68kops.c/h, 6280dasm.c, m68k_in.c, m68k.h and d68k.c/h.
-  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             : Added m68000\m68000.c, m68kconf.h, m68kmame.c/h, d68kconf.h and d68000.c/h. Removed m68000\m68kdasm.c, mc68kmem.c, cpufunc.c, cputbl.h, opcode0.c-e.c, dis68k.c and asm.bat. 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             : Added m68000\asm.bat. . 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             : Added m68000\asmintf.c and make68k.c. 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             : Added m68000\cycletbl.h. 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               : Added m68000\m68kdasm.c and dis68k.c. Removed m68000\m68000.txt. Aaron Giles made some changes to the 68000 emulator memory interface, and a new 68000 disassembler. Improved the 68000 cpu interface.
- 0.28               : Added m68000\m68000.h, mc68kmem.c, opcode0.c - opcodee.c, cpudefs.h, cpufunc.c., cputbl.h and readcpu.h. 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.128u4            : Aaron Giles fixed the 68EC020 CPU, which has graphics regression / game resets in most sets using the 68EC020 CPU.
- 0.128u3            : Aaron Giles updated cpuexec to compute the "perfect" interleave value taking into account the minimum number of cycles per instruction specified by the CPU core. Fixed incorrect minimum cpi in the 68020+ cores.
- 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.128u7            : Continued rewrite of the Motorola DSP56k CPU core [Andrew Gardner]: Fixed flag calculation and sign extension for numerous ops. Added rnd, mpysuuu, and dmac ops. Fixed do loop behavior to skip empty loops. Added stack underflow exception handling. Fixed update_handler for the DSP56k and Polygonet.
- 0.128u6            : Pointer-ified the dsp56k core [Quench].
- 0.128u3            : Continued rewrite of the Motorola DSP56k CPU core [Andrew Gardner, PhilB, RBelmont]: Added proper clock speed to plygonet.c and internal divider to dsp56k.c. Fixed up disassembler add/sub, 05xx, and bsr ops. Handle mysterious uuuuF instruction found in plygonet add op. Partially implemented add, sub, mac, mpy, inc, cmpm, macr, asr16, jscc, lea and movec ops. Added dual X memory read and data move with short displacement parallel moves.
- 0.128u2            : Rewrite of the Motorola DSP56k CPU core [Andrew Gardner]: Partially implemented inc24, asl4, bcc, brkcc and doForever ops. Added code for parallel address register update. Partially implemented tfr op. Polygonet now allows test mode to be run for a few seconds. Most IO is now known, though coin2 is still a mystery. Partially implemented move, asr4 and mpy ops.
- 0.128u1            : Rewrite of the Motorola DSP56k CPU core [Andrew Gardner]: Complete rewrite focusing on legibility and extensibility. 27/121 opcodes (mostly) implemented. Bugfix for reset status of interrupt priority bits. Bugfix for disassembly of register-to-register parallel data move. Added additional branch, move and bitfield ops. Polygonet Commanders now passes its memory test and uploads a new program. Implemented tst, or, jsr, rti, tst2, and 2 new movec ops. Added opbase handler to Plygonet driver.
- 0.127u6            : Andrew Gardner added additional Motorola DSP56k reset behavior.
- 0.127u5            : Rewrite of the Motorola DSP56k disassembler [Andrew Gardner]: Removes arbitrary opcode groupings in favor of flat decode model. Fixes a number of small issues with unknown opcodes. Added the final ALU parallel move ops. Fixes branch relative offset decoding.
- 0.126u4            : Andrew Gardner improved DSP56k CPU interrupt handling. Polygonet Commanders now advances past its first DSP handshake.
- 0.126u3            : Added cpu\dsp56k\dsp56pcu.c, dsp56mem.c and dsp56def.h. DSP56156 CPU Core updates [Andrew Gardner]: Rewrote core logic, communications, and interfaces. Added three parallel memory moves to the disassembler. Initial interrupt logic in place.
- 0.126u2            : DSP56156 Disassembler rewrite [Andrew Gardner]: Rearranged decoding behavior. Updated code style to MAME standards. Tested each single-word opcode with custom ROMs.
- 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.128u4            : Pointer-"ified" the S2650 core [Couriersud].
- 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             : Added s2650\s2650.c/h, s2650cpu.h and 2650dasm.c. 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.128u5            : Pointer-ified the CCPU core [Aaron Giles].
- 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.35b10            : Removed cpu\ccpu\cinedbg.c.
- 0.35b9             : Removed cpu\ccpu\ccpu.new.
- 0.35b8             : Changed name 'C-CPU' to 'CCPU'. Added cpu\ccpu\ccpu.new.
- 0.35b6             : Added cpu\ccpu\ccpu.c/h, ccputabl.c, ccpudasm.c and cinedbg.c.
- 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 / MCS-48

- 0.129              : Merged i8x41 (UPI-41) core into MCS-48 core [Aaron Giles]: All code now lives in mcs48.c. Rewrote disassembler as unified MCS-48/UPI-41 disassembler. Changed UPI-41 interfaces to match MCS-48. Added new master read/write interfaces for external access. Unified interface to 8243 expander chip. Converted tnzs and decocass to the new interfaces. Some minor MCS-48 cleanup. Added 8040/8050 variants. Aaron Giles changed videopkr MCS-48 P4 control register to the PROG line, which is more likely. The way to toggle the PROG line is to read/write/and/or to ports 4-7. Since the board doesn't list an 8243 port expander, it is likely the "writes" to port 4 are really just a mechanism to get the PROG line to toggle to clear the interrupt. Aaron Giles removed bogus port 4-7 definitions from MCS-48. Added i8243 implementation. Connected 8243 properly to monsterb and system 16a sound. Changed draw80pkr to connect the PROG line like videopkr. Aaron Giles cleaned up MCS48 to be dependent on a single makefile define, rather than separate defines for each CPU which didn't really buy us anything in terms of code size or performance.
- 0.128u5            : Aaron Giles fixed most sets using MCS48/51.C: Fatal Error when using -cheat trigger.
- 0.128u4            : Switched MCS48 to new memory functions [Couriersud].
- 0.128u3            : Couriersud converted the MCS-48 core to reference data via pointers.
- 0.127u5            : Aaron Giles fixed AF calculation in MCS48.
- 0.127u3            : Aaron Giles fixed memory handling of internal banks. They should be LOWER priority than the driver's memory maps. Reverted recent changes to MCS-48 core that were very hacky and which crashed many games. You can now properly override the internal memory map and do your own banking.
- 0.127u2            : Couriersud changed MCS-48 core to write p1 and p2 on reset. Use banking to handle EA line. Added MCS48_INTERNAL_ROMBANK define to header. Drivers which need to control the EA line have to initialize banking for internal/external rom. This is not yet optimal but works as expected with existing drivers and modified mario.c. Changed MCS-48 EA line handling to use an explicit bank for now. Aaron Giles changed all MCS-48 chips to have a 12-bit address space, regardless of internal ROM size.
- 0.127u1            : Changed cpu\i8039\i8039.c/h and 8039dasm.c to cpu\mcs48\mcs48.c/h and mcs48dsm.c. Significant cleanup/rewrite of the MCS-48 CPU core [?]: Renamed from i8039 to mcs48. Changed to use data address space for internal RAM. Added internal memory maps for variants with internal RAM/ROM. Added a number of variants from documentation. Removed redundant and unused definitions from header file. Renamed constants and functions to be MCS48* prefixed. Re-verified all opcode behaviors and timing. Changed illegal opcodes to count 1 cycle to avoid infinite loops. Changed EA behavior so that it is a push from the driver instead of a pull on each opcode fetch (this may change further in the future). Reimplemented IRQ generation and timer behavior according to documentation. Updated all drivers accordingly. Fixed several uses of PULSE_LINE, which no longer works.
- 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.35b10            : Removed cpu\i8039\dis48.c, makefile.txt and readme.txt.
- 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             : Added 8039dasm.c, dis48.c, makefile.txt and readme.txt. Andrea Mazzoleni added the I8039 to the debugger, using Mike Cuddy's disassembler.
- 0.30               : Added i8039\i8039.c/h. 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
- SOURCE: cpu\mcs48\mcs48.c
- 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   I8041

- 0.129              : Removed cpu\i8x41\i8x41.c/h, 8x41dasm.c and i8x41ops.c. Merged i8x41 (UPI-41) core into MCS-48 core [Aaron Giles]: All code now lives in mcs48.c. Rewrote disassembler as unified MCS-48/UPI-41 disassembler. Changed UPI-41 interfaces to match MCS-48. Added new master read/write interfaces for external access. Unified interface to 8243 expander chip. Converted tnzs and decocass to the new interfaces.
- 0.128u4            : Changed name 'I8X41' to 'I8041'. Added cpu\i8x41\i8x41ops.c. UPI-41/42 (I8x41) changes [Couriersud]: CPU/i8x41 should be renamed to UPI-4x, since UPI-41/42 was an intel chip family postponed for now until core moved to pointers. Removed I8041 definition from mcs48. Removed I8x41 cpu definition and config struct. Added I8041, I8741, I8042, I8242 and I8742 cpus to i8x41.c. Added internal memory maps. Internal ram now uses DATA memory space. Updated drivers. Increased interleave to 70 in decocass. This fixes decocass hanging in countdown around 13. No idea when this bug was introduced. Converted i8x41 to use pointers for state access. Separated opcodes into i8x41ops.c
- 0.125u7            : i8x41 improvements [Wilbert Pol]: Removed i8x41.ram hack from the i8x41 CPU core. Fixed disassembly for opcode 0x67. Added configurable i8x41/i8x42 subtype support. Fixed carry flag handling in ADDC A,#N instruction. Fixed carry flag handling in RLC A instruction. Updated the ram sizes (8041 uses 128 bytes, 8042 uses 256 bytes). Added support for re-enabling interrupts inside an interrupt handler. Fixed cycle count for DJNZ instruction.
- 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
- SOURCE: emu\cpu\i8x41\i8x41.c
- 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.128u7            : Aaron Giles rewrote 8080/8085 interrupt handling so that it makes sense. Changed callbacks to be specified in a config structure. Converted core to cpu_state_table. Changed to a single HAS_808X define for both cores. Fixed several drivers that used 8080/8085 interrupts in odd ways.
- 0.128u6            : Miodrag Milanovic fixed EI handling in the 8080/85 core to have a shadow like the Z80.
- 0.128u5            : Miodrag Milanovic fixed 8080 interrupt handling: 1. Previous implementation cleared interrupt enable bit on interrupt trigger which is wrong since interrupts should stay enabled.  2. Service interrupt number was not cleared after interrupt is executed, so if same one is triggered it will not be catched.
- 0.127u5            : Miodrag Milanovic fixed all drivers using a 8080 CPU: 8080 core has problem with score/credit counts and other variables.
- 0.127u3            : 8080/8085 CPU core updates [Miodrag Milanovic]: ANA/ANI instruction, HF flag was not set right because error in calculation of it (missing brackets). 8080 have NF flag always set (it is not used flag but bit is always set). Added support for status output lines.
- 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.131              : Aaron Giles fixed XF flag in the 8085A core.
- 0.128u7            : Aaron Giles rewrote 8080/8085 interrupt handling so that it makes sense. Changed callbacks to be specified in a config structure. Converted core to cpu_state_table. Changed to a single HAS_808X define for both cores. Fixed several drivers that used 8080/8085 interrupts in odd ways. Aaron Giles added the concept of a cpu_state_table, which is supplied by the CPU cores and which describes all the register state accessible to the debugger and other subsystems. The format of the table is such that most data can be simply fetched from memory without the further involvement of the CPU core, including the display of common formats. Extensibility points are available for custom display and for importing/exporting the data to intermediate variables for more complicated scenarios. Updated the 8085 core to use this.
- 0.128u6            : Curt Coder added INTE and state word callbacks to the i8085. Pointer-ified the i8085 CPU core [Aaron Giles]. Miodrag Milanovic fixed EI handling in the 8080/85 core to have a shadow like the Z80.
- 0.127u3            : 8080/8085 CPU core updates [Miodrag Milanovic]: ANA/ANI instruction, HF flag was not set right because error in calculation of it (missing brackets). 8080 have NF flag always set (it is not used flag but bit is always set). Added support for status output lines.
- 0.125u5            : Miodrag Milanovic improved 8085 timing and fixed flag calculations based on differences between it and the 8080.
- 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             : Added i8085\i8085.c/h, i8085cpu.h, i8085daa.h and 8085dasm.c. 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.129              : Aaron Giles fixed i86 core so that REP instructions with high interleave actually make forward progress.
- 0.128u7            : Cleaned up i86/i286/i386/nec/v30mz headers [Aaron Giles]: Renamed i86.h -> i86priv.h. Renamed i86intrf.h -> i86.h. Consolidated i88intrf.h, i186intf.h, i188intf.h, etc into i86.h. Aaron Giles added the concept of a cpu_state_table, which is supplied by the CPU cores and which describes all the register state accessible to the debugger and other subsystems. The format of the table is such that most data can be simply fetched from memory without the further involvement of the CPU core, including the display of common formats. Extensibility points are available for custom display and for importing/exporting the data to intermediate variables for more complicated scenarios. Updated the i86 core to use this.
- 0.128u6            : Removed i86\v30.h, v30intf.h, v20intf.h, v33intf.h, instrv30.c, instrv30.h and tablev30.h. Pointer-ified the i86 CPU core [Aaron Giles].
- 0.119u3            : Phil 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             : Added cpu\i86\i86time.c and instr286.h. Removed cpu\i86\i86intrf.h, instr.h and i86.txt. Lots of changes to some CPU cores (mostly i86) [Peter Trauner, Juergen Buchmueller, Aaron Giles].
- 0.37b2             : Added cpu\i86\i86intf.h, instr86.c/h, table86.h and i86.txt. Added cpu\i86\v20intf.h, v30.h, v30intf.h, instrv30.c/h, v33intf.h and tablev30.h.
- 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             : Added i86\i86dasm.c. 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.30               : Removed i86\i86.txt.
- 0.24               : Added i86\i86intrf.h, ea.h, host.h and modrm.h. Removed i86\i86dasm.h, mytypes.h, global.h, debugger.c/h and copyright. Fabrice Frances submitted a new faster I86 emulator. The entire I86 directory is changed, and most of Gottlieb games are now faster.
- 0.18               : Added i86\i86dasm.h and debugger.c/h. 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               : Added i86\i86.c/h, instr.h, mytypes.h, global.h and copyright. 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.128u7            : Removed cpu\i86\i88intf.h.
- 0.118u3            : Changed name 'I8088' to '8088'.
- 0.37b2             : Added cpu\i86\i88intf.h.
- 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.128u7            : Removed cpu\i86\i186intf.h.
- 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.
- 0.37b2             : Added cpu\i86\i186intf.h, instr186.c/h and table186.h.
- 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

- 0.128u7            : Removed cpu\i86\i188intf.h.
- 0.37b2             : Added cpu\i86\i188intf.h.
- NOTES: The I80188 has a 8bit data bus.
- SOURCE: cpu\i86



6.12  I80286

- 0.129              : Aaron Giles fixed cpu.mak dependencies for i286.
- 0.128u7            : Changed cpu\i86\i286intf.h to cpu\i86\i286.h. Cleaned up i86/i286/i386/nec/v30mz headers [Aaron Giles]: Renamed i86.h -> i86priv.h. Renamed i86intrf.h -> i86.h. Consolidated i88intrf.h, i186intf.h, i188intf.h, etc into i86.h.
- 0.128u6            : Pointer-ified the i286 CPU core [Aaron Giles].
- 0.125u9            : I80286 update [Wilbert Pol]: Fixed POP ES in protected mode.
- 0.125u3            : Removed cpu\i86\i286.h. Wilbert Pol fixed memory access in the 80286 CPU core which made i286.h obsolete. Changed CPUINFO_INT_MAX_INSTRUCTION_BYTES to prevent crashes during disassembly.
- 0.125u2            : Wilbert Pol fixed 80286 databus widths.
- 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.37b2             : Added cpu\i86\i286.c/h, i286intf.h, instr286.c and table286.h.
- 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.128u7            : Changed cpu\i386\i386intf.h to cpu\i386\i386priv.h. Cleaned up i86/i286/i386/nec/v30mz headers [Aaron Giles]: Renamed i86.h -> i86priv.h. Renamed i86intrf.h -> i86.h. Consolidated i88intrf.h, i186intf.h, i188intf.h, etc into i86.h.
- 0.128u6            : Pointer-ified the i386 CPU core [Aaron Giles].
- 0.126u5            : Atari Ace fixed the I386 CPU core's BSR implementation for the case where the high bit is set.
- 0.125u4            : Aaron Giles added fisttp opcode to i386 disassembler.
- 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  i860XR

- 0.129u1            : Added cpu\i860\i860dec.c and i860dis.c. Intel i860 CPU core added [Jason Eckhardt]. Renamed 'i860' ti 'i860XR'.
- 0.129              : Added extremely preliminary i860 disassembler and hooked it up to the vcombat driver [Jason Eckhardt, Andrew Gardner].
- SOURCE: cpu\i860\i860.c/h and i860dasm.c.
- PCB: 


6.16  i960KB

- 0.128u6            : Robiza fixed i960 nor opcode and added notor opcode.
- 0.128u4            : i960 core switched to pointer state access [Couriersud].
- 0.126u2            : ElSemi fixed incorrect I960 behavior when generating interrupts.
- 0.126u1            : i960 [ElSemi]: Respect the rounding mode for CVTRI.
- 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.17  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.18  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.128u6            : Pointer-ified the TMS7000 CPU core [Aaron Giles].
- 0.111u2            : Added TMS7000 emulator [Tim Lindner].
- SOURCE: cpu\tms7000\tms7000.c


7.2   TMS99xx
- 0.128u6            : Pointer-ified the TMS99xx CPU core [Aaron Giles].
- 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.128u4            : Aaron Giles fixed missing *_get_info functions in the TMS9900 core.
- 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.36b15            : Added cpu\tms9900\9900stat.h.
- 0.36b13            : Added cpu\tms9900\99xxcore.h and 99xxstat.h. Removed cpu\tms9900\9900stat.h.
- 0.35b2             : Added tms9900\9900stat.h. Removed tms9900\tms9900c.h.
- 0.34b6             : Added tms9900\tms9900.c/h, 9900dasm.c and tms9900c.h. 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.36b13            : Added cpu\tms9900\tms9980a.c.
- 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.
- 0.36b13            : Added cpu\tms9900\tms9995.c.
- 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.130u3            : Olivier Galibert reverted recent TMS32025 timing change which busted Cool Pool sound.
- 0.130u2            : TMS320C25 fixes and enhancements [Olivier Galibert]: Accept IRQs on IDLE. Actually count irq processing and instruction fetching cycles. Add support for external serial frame sync with internal triggering (aka TXM=1 and FSM=1).
- 0.128u6            : Pointer-ified the TMS32025 core [Quench].
- 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.128u4            : Pointer-ified the TMS32031 core [Aaron Giles].
- 0.125u9            : Aaron Giles fixed TMS32031 so that it doesn't call the debugger if not enabled.
- 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.128u6            : Pointer-ified the TMS32051 CPU core [Aaron Giles]
- 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.128u7            : Aaron Giles added the concept of a cpu_state_table, which is supplied by the CPU cores and which describes all the register state accessible to the debugger and other subsystems. The format of the table is such that most data can be simply fetched from memory without the further involvement of the CPU core, including the display of common formats. Extensibility points are available for custom display and for importing/exporting the data to intermediate variables for more complicated scenarios. Updated the TMS340x0 core to use this.
- 0.128u6            : Atari Ace modified the tms34010.h interface to eliminate some more global Machine variables. More deprecat.h includes eliminated.
- 0.128u4            : Aaron Giles converted TMS340x0 cores to be pointer-based.
- 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            : Phil Bennett changed the TMS340x0 core to clear the HSTCTLH NMI bit on an acknowledge. Phil 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             : Added cpu\tms34010\34010gfx.c. 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.
- 0.36b6             : Added cpu\tms34010\makefile.
- 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.34b4             : Added tms34010\34010ops.h.
- 0.34b2             : Added tms34010\tms34010.c/h, 34010dsm.c, 34010fld.c, 34010ops.c, 34010tbl.c and dis34010.c. 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.128u7            : Aaron Giles added the concept of a cpu_state_table, which is supplied by the CPU cores and which describes all the register state accessible to the debugger and other subsystems. The format of the table is such that most data can be simply fetched from memory without the further involvement of the CPU core, including the display of common formats. Extensibility points are available for custom display and for importing/exporting the data to intermediate variables for more complicated scenarios. Updated the TMS340x0 core to use this.
- 0.128u4            : Aaron Giles converted TMS340x0 cores to be pointer-based.
- 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            : Phil Bennett changed the TMS340x0 core to clear the HSTCTLH NMI bit on an acknowledge. Phil 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)



7.9   TMS57002

- 0.130              : Olivier Galibert added two missing instructions to TMS57002 and hack up the coef update. The real way coefficient updates are handled is a little too complex for now, but the hack throttles the update speed to the real rate given the way konami uses it (once per sync). It's near impossible to use it in a different way anyway.
- 0.129u6            : TMS57002, don't abort on unimplemented instructions [Olivier Galibert].
- 0.129u4            : Added cpu\tms57002\tms57002.c/h, tmsinstr.lst and tmsmake.c. TMS57002 preliminary implementation [Olivier Galibert].
- NOTES: The TI TMS57002 is a effect DSP.
- GAMES: Konami System GX
- SOURCE: cpu\tms57002\tms57002.c
- PCB: TMS57002DPHA DSP, QFP80 (G-Darius, Raystorm), TMS570020PHA (Le2, RacinForce)





8.    Hitachi

8.1   HD6309

- 0.128u4            : Pointer-ified the HD6309 CPU core [Couriersud].
- 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'.
- 0.37b6             : Added cpu\hd6309\hd6309.c/h, 6309tbl.c, 6309ops.c and 6309dasm.c.
- 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/3xx
- 0.129u3            : Luca Elia implemented a few more H8/3xx instructions.
- 0.128u4            : Changed cpu\h83002\h83002.c/h to h8_8.c, h8_16.c, h8ops.h and h8.h. Big H8 update [R. Belmont]: Converted H8 CPUs to the new memory functions and un-deprecat'ed the H8. Pointer-ified all H8 cores. Some cleanup and renames toward additional future work.
- 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.
- SOURCE: cpu\h83002\h8_16.c


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

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


8.53  H8/3002

- 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.54  H8/3007
- 0.129u3            : Luca Elia implemented a few more H8/3xx instructions and added Funcube 2 + 4 to seta2.c.
- 0.128u4            : Big H8 update [R. Belmont]: Converted H8 CPUs to the new memory functions and un-deprecat'ed the H8. Pointer-ified all H8 cores. Some cleanup and renames toward additional future work.
- 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.55  H8/3044
- 0.128u4            : Big H8 update [R. Belmont]: Converted H8 CPUs to the new memory functions and un-deprecat'ed the H8. Pointer-ified all H8 cores. Some cleanup and renames toward additional future work.
- 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.56  H8/3334
- 0.128u4            : Big H8 update [R. Belmont]: Converted H8 CPUs to the new memory functions and un-deprecat'ed the H8. Pointer-ified all H8 cores. Some cleanup and renames toward additional future work. Added H8/3334 (14745600 Hz) CPU3 and IC3 (256k) from I/O board (HD643334 H8/3334 MCU code) to Time Crisis 2.
- GAMES: Motocross Go! and Time Crisis 2


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


8.58  H8/3344
- 0.128u4            : Big H8 update [R. Belmont]: Added support for 8-bit H8 family MCUs, starting with the H8/3344. Pointer-ified all H8 cores. Some cleanup and renames toward additional future work. Added extremely preliminary support for I/O boards to the Namco System 23 with the H8/3344.




8.6   Z180

- 0.128u7            : Aaron Giles added the concept of a cpu_state_table, which is supplied by the CPU cores and which describes all the register state accessible to the debugger and other subsystems. The format of the table is such that most data can be simply fetched from memory without the further involvement of the CPU core, including the display of common formats. Extensibility points are available for custom display and for importing/exporting the data to intermediate variables for more complicated scenarios. Updated the Z180 core to use this.
- 0.128u6            : Pointer-ified the Z180 core [Aaron Giles].
- 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.7   FD1089

- 0.127u1            : Atari Ace moved FD1089 decryption keys to external files.
- 0.126u5            : Nicola Salmoria updated the FD1089 decryption algorythm to use the real keys generated by the LCG as found by Andreas Naive. The algorithm is more complex than it should be, but I haven't been able to simplify it more. The keys are still embedded in the source. It would now be reasonable to move them to external files; however, for several games we only have partial keys so the files would need to be BAD_DUMP.
- 0.125u4            : Added machine\fd1089.h.
- 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 68000 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) mappings. Decryption works on 16-bit words, but only 8 bits are affected, the other 8 are left untouched. A special value in internal RAM disables the encryption, 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 contains the 8-bit key 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 it was done. 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. Like for the MC8123, the contents of the internal RAM were generated using a linear congruential generator, so the whole key can be generated starting from a single 24-bit seed. Note however that the "don't decrypt" data sections need special treatment so it's not possible to derive the precise key without access to the CPU.
- SOURCE: machine\fd1089.c
- GAMES: Action Fighter (Sega 1986), Dunk Shot (1987)
- PCB: Hitachi FD1089A 317-0018 (Afighter)


8.8   FD1094

- 0.128u7            : Added machine\fddebug.h.
- 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.9   FD1149
- NOTES: The FD1149 CPU is undumpable yet!
- GAMES: Sega - Burning Rival F1 (1992), Super Visual Football (1994)
- SOURCE: drivers\segas32.c


8.A   SH-1
- 0.127              : R. Belmont added SH-1 CPU support, including lower precision on MAC.W and locking out SH-2 only instructions.
- GAMES: Cool Riders (Sega 1995)


8.B   SH-2 / SH7600 family

- 0.129u6            : Aaron Giles moved SH2 set info functions to direct calls.
- 0.129u2            : Aaron Giles tweaked a few oddities in the SH2 DRC.
- 0.128u6            : Pointer-ified the SH2 CPU core [Aaron Giles].
- 0.128u5            : Aaron Giles fixed subtle timing calculation problems that affected SH-2 timers.
- 0.128u4            : Aaron Giles removed cpu_num info from SH2 in favor of just keeping the device object.
- 0.127u8            : R. Belmont fixed SH2 DRC's handling of internally generated IRQs, and fixed compiling in interpreter mode.
- 0.127              : SH-2 DRC updates [R. Belmont]: Moved IRQ handling front-end into recompiled code. Added TSTM/ANDM/XORM instructions. Oliver Stoenberg removed more unprintable characters in SH-2 disassembler.
- 0.126u3            : SH2DRC [R. Belmont, based on an idea by Mariusz Wojcieszek]: Add PC-relative load optimization and ability to disable if necessary. SH2DRC [R. Belmont, Aaron Giles]: Add SUBV, replace ADDV with C version as a precaution. (Fixes most of Mantis #2026, except the part which is a separate bug). Added new implementation which uses flags directly, keeping the C versions in reserve in case they are needed. Aaron Giles simplified SH2 DRC shift/rotate instruction implementations. Oliver Stoenberg removed of unprintable chars (newlines) in SH-2 disassembler.
- 0.126u1            : Added cpu\sh2\sh2drc.c and sh2fe.c. UDRC-based SH-2 dynamic recompiler [R. Belmont]: All games on all drivers should work as before except "colmns97" and "stress" which crash due to sound system trouble. All idle skips are still included. They are quite a bit less effective than they were on the interpreter, but they still give a boost. Fast RAM bypass is not included yet so this does not represent final performance. That said, it's consistently faster than the interpreter even now. Example: sfiii3 on 0.126 gets 609% on the interpreter and 961% on the DRC.
- 13th July      2008: R. Belmont - The initial version of the SH-2 UDRC frontend has been submitted. It's missing the *direct RAM* feature that will make it much faster, but performance is already promising. For example, a -nosound -nothrottle -str 120 run on sfiii3 gets 609% on stock 0.126 and 961% with the DRC. The results are less flashy on more intense games like diehard (230% on 0.126, 278% on the DRC), but there's still a consistent gain over the interpreter and hopefully more to come.
-  3rd July      2008: R. Belmont - The SH-2 DRC successfully got Cyvern past the on-screen POST last night, but that revealed a problem with cycle counting that was making MAME timing and interrupts work poorly at best. I fixed that, but there's now a bug where it crashes trying to resume after handling an interrupt. Never a shortage of fun with this stuff!
- 0.125u9            : Added cpu\sh2\sh2comn.c/h. SH2 core [R. Belmont]: Refactored to separate out things that aren't part of the interpreter. Converted context struct to go through a pointer.
-  2nd July      2008: R. Belmont - I've been working on a MAME UDRC frontend for the SH-2 for just under a week now. Last night it finally made it all the way through the suprnova BIOS and into the Cyvern boot code without errors (including handling interrupts). There are still several instructions left to implement before it actually shows something, but so far so good so what, right? This will speed up ST-V (and Saturn in MESS), Kaneko SuperNova, Psikyo SH-2, and CPS3. And SH-2 is a pure subset of SH-4 (aside from different boot vector semantics) so once done this frontend will make a fine starting point for an SH-4 UDRC.
- 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.C   SH-4

- 0.130u3            : ElSemi and Angelo Salese added direct mode JVS command, used by the I/O for the later NAOMI games.
- 0.128u6            : Pointer-ified the SH4 CPU core [Aaron Giles].
- 0.127u1            : SH4, NAOMI and Hikaru updates [Samuele Zannoli]: Fixed SH-4 core to support multiple SH-4s. Fixed LDCSR instruction. Fixed SH-4 I/O ports. Skeleton Hikaru driver with memory maps and both SH-4s. Fixed JVS/Maple translation so NAOMI 2 BIOS runs.
- 0.127              : Added cpu\sh4\sh4comn.c/h. R. Belmont split out SH-4 non-interpreter-specific stuff to sh4comn.c.
- 0.126u1            : SH-4 update [Samuele Zannoli]: Fixed TRAPA and some versions of FMOV. Improved disassembly for MOV.W, MOVA, MOV.L, FIPR and FSCA.
-  2nd July      2008: R. Belmont - I've been working on a MAME UDRC frontend for the SH-2 for just under a week now. Last night it finally made it all the way through the suprnova BIOS and into the Cyvern boot code without errors (including handling interrupts). There are still several instructions left to implement before it actually shows something, but so far so good so what, right? This will speed up ST-V (and Saturn in MESS), Kaneko SuperNova, Psikyo SH-2, and CPS3. And SH-2 is a pure subset of SH-4 (aside from different boot vector semantics) so once done this frontend will make a fine starting point for an SH-4 UDRC.
- 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   uPD7806

- 0.129u2            : Wilbert Pol fixed cpu reset for upd78c06.
- 0.123u3            : Wilbert Pol added basic support for the NEC uPD7801, uPD78C05 and uPD78C06 CPUs to the uPD7810 CPU core.



9.6   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.7   uPD7810

- 0.128u6            : Pointer-ified the uPD7810 CPU core [Aaron Giles].
- 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.8   NEC Vxx

- 0.128u7            : Changed cpu\nec\necintrf.h to cpu\nec\necpriv.h. Cleaned up i86/i286/i386/nec/v30mz headers [Aaron Giles]: Renamed i86.h -> i86priv.h. Renamed i86intrf.h -> i86.h. Consolidated i88intrf.h, i186intf.h, i188intf.h, etc into i86.h.
- 0.128u2            : NEC CPU core improvements [Couriersud]: Removed another speed hack in the NEC core. Renamed "FETCH" to "FETCH()" (macros used as functions should look like functions). Preparation for opcode prefetch timing. Improved prefetch timing calculation. Prefetch timing now also used by V20 and V33. Moved some static variables into cpu context. nec_reset now explicitly clears context variables. All cpus now share nec_execute.
- 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.36b7             : Changed cpu\nec\ea.h, host.h, instr.h and modrm.h to cpu\nec\necea.h, nechost.h, necinstr.h and necmodrm.h.
- 0.36b6             : Added cpu\nec\nec.c/h, necdasm.c, necintrf.h, instr.h, host.h, ea.h and modrm.h
- SOURCE: cpu\nec\nec.c


9.81  V20

- 0.128u2            : NEC CPU core improvements [Couriersud]: Removed another speed hack in the NEC core. Renamed "FETCH" to "FETCH()" (macros used as functions should look like functions). Preparation for opcode prefetch timing. Improved prefetch timing calculation. Prefetch timing now also used by V20 and V33. Moved some static variables into cpu context. nec_reset now explicitly clears context variables. All cpus now share nec_execute.
- 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.82  V30

- 0.128u4            : Pointer-ified NEC V30 CPU [Couriersud].
- 0.127u7            : Angelo Salese fixed old regression bug in Sengoku Mahjong that made the controls not work when the V30 CPU core was converted to 16-bit. Specifically, the game accesses the multiplexer with a word write instead of a byte write.
- 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, Phil 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.83  V30MZ

- 0.128u7            : Changed cpu\v30mz\necintrf.h to cpu\v30mz\nec.h. Cleaned up i86/i286/i386/nec/v30mz headers [Aaron Giles]: Renamed i86.h -> i86priv.h. Renamed i86intrf.h -> i86.h. Consolidated i88intrf.h, i186intf.h, i188intf.h, etc into i86.h.
- 0.128u6            : Pointer-ified the V30MZ core [Aaron Giles].
- 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.84  D80000

- 0.124u5            : Robiza fixed another opcode in Match It II and verified a "not sure" opcode in clone Bomber Man.
- 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.85  DYNA CPU91A

- 0.129u2            : Robiza mapped two more opcodes for Cherry Bonus 2001.
- 0.129              : Robiza discovered numerous new opcodes for Cherry Bonus 2001.
- NOTES: The CPU91A is a encrypted cpu like NEC V25/35 used in some IREM game.
- SOURCE: drivers\cb2001.c
- PCB: DYNA CPU91A-011-0016JK004, QFP84 (cb2001)


9.86  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.87  V33

- 0.128u6            : Couriersud fixed raster effects in Ninja Baseball Batman by altering the V33 prefetch timing (just a guess as no documentation has been found).
- 0.128u2            : NEC CPU core improvements [Couriersud]: Removed another speed hack in the NEC core. Renamed "FETCH" to "FETCH()" (macros used as functions should look like functions). Preparation for opcode prefetch timing. Improved prefetch timing calculation. Prefetch timing now also used by V20 and V33. Moved some static variables into cpu context. nec_reset now explicitly clears context variables. All cpus now share nec_execute.
- 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.88  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.89  V60

- 0.128u6            : Pointer-ified the V60 core [Aaron Giles].
- 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.8A  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.8B  V810

- 0.128u6            : Pointer-ified the V810 core [Aaron Giles].
- 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.128u6            : Pointer-ified the H6280 CPU core [Andrew Gardner].
- 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             : Added cpu\h6280\h6280.c/h, h6280ops.h and tblh6280.c. 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.128u6            : Pointer-ified the ARM CPU core [Andrew Gardner].
- 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.
- 0.37b5             : Added cpu\arm\arm.c/h 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.129u1            : Atari Ace rewrote some abuses of the ARM7 core HANDLER macros to use _func types instead.
- 0.128u5            : ARM7 updates [R. Belmont]: Pointer-ified ARM7 core. Added disassembler and execution support for ARMv5 LDRD/STRD instructions. 39in1 now makes it until it needs the MMU.
- 0.127u2            : R. Belmont removed unnecessary ARM7 hooks so MRC and MCR disassemble properly.
- 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 ???
- 0.129u4: Christophe Jaillet removed some unused code from deco_mlc.c.
- 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.129u2            : Wilbert Pol improved implementations for undocumented instructions 63, 67, 6f, 73, 77, 7b, 7f, 9c, 9e, ab, e3, e7, ef, f3, f7, fb and ff in the n2a3 cpu core.
- 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.
- 0.36RC1            : Changed cpu\m6502\tbln2a03.c to tn2a03.c.
-  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.128u5            : Pointer-ified the 65816 core [R. Belmont].
- 0.127u5            : 65816/377xx update [ShimaPong]: Fixed disassembly of BRL.
- 0.127              : R. Belmont added save states to 65816 CPU.
- 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.
- 0.37b6             : Added cpu\g65816\g65816.c/h, g65816ds.c/h, g65816cm.h, g65816op.h 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.129u1            : Atari Ace removed the interface declarations and functions in the SPC700 core. Most of it is handled by CPU_GET_INFO, some of it was no longer implemented, and since pointerization it wasn't possible to call it externally anyhow.
- 0.128u5            : Pointer-ified the SPC700 core [R. Belmont],
- 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.
- 0.37b7             : Added cpu\spc700\spc700.c/h and spc700ds.c/h.
- 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.129u1            : Atari Ace made all SNES obc1_, DSP1_ and DSP2_ exports static.
- 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   DSP-2

- 0.129u1            : Atari Ace made all SNES obc1_, DSP1_ and DSP2_ exports static.
- 0.127u7            : Added machine\snesdsp2.c and snesobc1.c. Fabio Priuli and Byuu added emulation for SNES special chips DSP-2 & OBC-1: Added sources snesdsp2.c & snesobc1.c. Removed special chips detection from MAME. Modified memory handlers to account for the new chips.
- NOTES: SNES "DSP-2" add-on chip. Original C++ code by byuu, based on research by Overload. MAME/MESS C conversion by etabeta.
- SOURCE: machine\snesdsp2.c



11.6   RSP

- 0.128u6            : Pointer-ified the RSP CPU core [Aaron Giles].
- 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.7   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.8   RDP
- 26th April 2008: MooglyGuy - I found that the N64 silently treats such textures as 4-bit Color Indexed (palettized) or 8-bit Color Indexed. In addition, the current RDP implementation in MESS fails to emulate the fact that a 4-bit CI texture can select which of 16 different palettes to use; it's hard-coded to index 0. After fixing this functionality, Madden 64 was fixed.
- 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.9   Minx
- 0.125u5            : Wilbert Pol fixed handling of the U register in the RET instructions and when taking an interrupt in the Nintendo Minx CPU core.
- 0.125u4            : Some Nintendo Minx CPU core updates [Wilbert Pol]: Styling changes. Added instruction cycle counts. Added interrupt support. Added HALT support. Fixed INT instruction. Added incomplete support for DIV and MUL instructions. Fixed MOV [#nnnn],BA and MOV [#nnnn],HL instructions. Fixed interrupt handling. Fixed opcodes 45, 4D, 55, 5D, B5, B6, B7, FC, FD and CF 70-7F. Fixed flag results for INC, DEC, AND, OR and XOR instructions.
- 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.128u5            : Pointer-ified the T-11 core [Aaron Giles].
- 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             : Added t11\t11.c/h, t11ops.c, t11table.c and t11dasm.c. 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.128u7            : Aaron Giles changed ADSP21xx cores to accept a configuration struct instead of using set_info to specify serial port callbacks. Simplified the ADSP21xx get/set info significantly. Removed support for only including certain variants of the chips; they are now either all supported or all unsupported. Aaron Giles added the concept of a cpu_state_table, which is supplied by the CPU cores and which describes all the register state accessible to the debugger and other subsystems. The format of the table is such that most data can be simply fetched from memory without the further involvement of the CPU core, including the display of common formats. Extensibility points are available for custom display and for importing/exporting the data to intermediate variables for more complicated scenarios. Updated the ADSP21xx core to use this.
- 0.128u6            : Aaron Giles added wrappers for ADSP21xx callbacks. Added device parameters to them. Updated IRQ setters to use generic_pulse_irq_line().
- 0.128u4            : Switched ADSP21xx to new memory functions [Couriersud].
- 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.128u3            : Aaron Giles converted the ADSP2100 core to reference their data via pointers instead of global structs, in anticipation of future changes.
- 0.125u9            : Aaron Giles split ADSP2100 execution loop between debug/non-debug.
- 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.
- 0.36b12            : Added cpu\adsp2100\adsp2100.c/h, 2100ops.c and 2100dasm.c.
-  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

- 0.128u6            : Pointer-ified the SHARC core [Atari Ace].
- 0.125u7            : Aaron Giles added save state support to the SHARC CPU core.
-  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.128u6            : Pointer-ified the DSP32 core [Aaron Giles].
- 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.128u4            : Pointer-ified the ASAP core [Aaron Giles].
- 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.129u1            : Nathan Woods fixed multisession bug in the Jaguar implementation.
- 0.128u4            : Pointer-ified the Jaguar CPU core [Aaron Giles].
- 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.128u5            : Updated T5182 memory mapping a bit to properly handle mirrored areas. Added comments about how shared ram works [Lord Nightmare].
- 0.127              : Lord Nightmare updated the T5182 documentation/pinout.
- 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-900
- 0.131              : Added cpu\tlcs900\tlcs900.c/h, 900tbl.c and dasm900.c. Wilbert Pol added Toshiba TLCS-900/H CPU core.
- SOURCE: cpu\tlcs900\tlcs900.c


13.61  TLCS-90
- 0.130u2            : Fixed pending IRQs handling in the TLCS-90 CPU core [Luca Elia].
- 0.128u6            : Pointer-ified the TLCS-90 core [Atari Ace].
- 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.62  TMP90841
- 0.111u1            : Luca Elia added new Toshiba TMP90840/TMP91640 CPU core.
- SOURCE: cpu\tlcs90\tlcs90.c
- PCB: TMP90C841, SDIP64 (Raphero, Cafedoll)


13.63  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


14.1   Konami 1

- 0.125u4            : Changed machine\konami.c to machine\konami1.c.
- 0.30               : Added machine\konami.c.
- NOTES: The Konami_1 CPU is a 6809 with opcodes scrambled.
- SOURCE: machine\konami1.c
- PCB: Konami custom chip, DIP42 or DIL42, Fujitsu fab., A072 (Megazone), A082 (Jailbrek) and A087 (Finalizr)


14.2    KONAMI

- 0.128u6            : Changed Konami setlines callback to pass a device. Updated all drivers accordingly [Aaron Giles, Atari Ace]. Pointer-ified the Konami core [Aaron Giles].
- 0.126u1            : Nicola Salmoria added save state suport to Konami CPU & Aliens.
- 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             : Added cpu\konami\konami.c/h, konamops.c, konamtbl.c and knmidasm.c. Konami 052001/053248 CPU emulation, used by many games [Ernesto Corvi, Manuel Abadia].
- SOURCE: cpu\konami\konami.c
- 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.130u1            : R. Belmont updated MIPS III RA before executing the delay slot.
- 0.130              : Aaron Giles added function calls to replace the MIPS3 and PowerPC DRC's various CPU_SET_INFO bits.
- 0.125u9            : MIPS3 recompiler [Aaron Giles]: Don't generate compare interrupts unless the compare register was written to; fixes hangs in blitz, calspeed and others. Stash jump target address before executing delay slot; also, don't update link register until delay slot has finished executing; fixes hang in gauntleg. Marked IDT instructions for R4650 only. Accounted for time taken in throwaway likely branch slots. Fixed jalr to respect the correct link register. Fixed c.eq, c.lt, c.le to fail if unordered. Fixed swxc1, sdxc1 to use the correct source register  (fixes many Gauntlet problems). Fixed CCR31 display in debugger. Fixed LWXC1/LDXC1; corrects gauntleg camera.
- 0.125u7            : Aaron Giles added save state support to the MIPS3 recompiler and virtual TLB system. Atari Ace corrected the dependencies for the MIPS core.
- 0.125u6            : Added cpu\vtlb.c/h. MIPS3 recompiler [Aaron Giles]: Added UML comments for common state variables. Removed some unused fields. Implemented LL/LLD/SC/SCD (only works single-processor for now). Created common virtual TLB managment module. Updated MIPS and PowerPC code to make use of it [Aaron Giles].
- 0.125u5            : MIPS recompiler update [Aaron Giles]: Updated to no longer explicitly specify flags. Tweaked register tracking to match new DRC frontend system. Updated UML logging to output new frontend statistics. Fixed left/right accesses to work with recent memory handler changes.
- 0.125u4            : MIPS3 dynamic recompiler [Aaron Giles]: Fixed Cause register for bad COP instructions. Updated to use new/changed opcode forms. Changed context switch so that it only swaps a single pointer.
- 0.125u3            : MIPS core changes [Aaron Giles]: Renamed struct mips3_config -> mips3_config. Updated all drivers to the new names. Removed MIPS3DRC_STRICT_COP0 flag, which is no longer used. A few minor cleanups. Moved implementation-specific state into a pointer hanging off of the core MIPS3 state. Removed large context in favor of a pointer to the large context to help improve context switch times.
- 0.125u1            : Removed cpu\mips\mdrc64.c and cpu\mips\mdrcold.c.
- 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             : Added cpu\mips\mips.c/h, mipsdasm.c, dismips32.mak and dismips.c. 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



15.1   R3000

- 0.129u4            : R. Belmont improved disassembly of R3000 code that uses the TLB or FPU.
- 0.128u3            : Aaron Giles converted the R3000 core to reference their data via pointers instead of global structs, in anticipation of future changes.
- 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.11  R3560
- NOTES: Super Real Mahjong P5 uses in MAME the R3000 (little) CPU instead of the R3560.
- PCB: R3560 (Srmp5)



15.2   R4300
- 0.130u1: R. Belmont added specific support for NEC VR4300/4310 CPUs.
- NOTES: MAME uses for Eleven Beat or Magical Tetris Challenge the R4600 (big) CPU instead of the R4300.
- PCB: NEC D30200GD-100 VR4300, QFP120 (NeoGeoHyper64), CPU-NUS A (11beat, Mtetrisc)



15.21  R4310
- 0.130u1: R. Belmont added specific support for NEC VR4300/4310 CPUs.
- NOTES: 
- PCB: 



15.3   R4600
- 0.128u6            : Pointer-ified the MIPS 3 core [Aaron Giles].
- 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.31  IDT R4650 (little)
- 0.104u4            : R. Belmont hooked up the R4650 properly in the MIPS recompiler.


15.32  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.4   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.8   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.9   PSX CPU

- 0.130              : smf fixed PSX CPU disassembly of -$8000, it was showing up as -$0.
- 0.129              : smf implemented GTE divider using reciprocal table derived by pSXAuthor, this should allow the results to be calculated as inaccurately as the real hardware.
-  3rd January   2009: smf - Last, but by no means least is pSXAuthor's investigation into the GTE divider. It has been known for a while that emulation of the divider is too accurate. I spent a little time looking at it last year & hypothisized that it multiplied using a reciprocal table. Independently pSXAuthor actually did the hard work of reverse engineering it & has kindly donated his discoveries. So everyone can enjoy innaccurate divisions. I doubt it has a major effect on anything, but it makes it easier to compare GTE results from the emulator to be compared to the results on a PlayStation. I plan on restarting the work to improve MAME's GTE, I have some fixes from last year but so much has changed since then that it's not just a copy & paste. BTW I think I introduced a bug in the division but it probably won't have a visible effect, but if you're thinking of taking the code for another emulator it might be worth waiting a while.
- 0.128u4            : Changed cpu\mips\mipsdasm.c to psxdasm.c. Pointerified the PSX CPU core and switched it to the new memory functions. Changed some MIPS_* to PSXCPU_* [smf].
- 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.91  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: Phil 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: Phil 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 / Real Time Image Processor

- 0.129              : Added cpu\esrip\esrip.c/h.
- NOTES: http://www.bitsavers.org/pdf/amd/_dataSheets/29116_dataSheet_Mar86.pdf
- PCB: AM29116DC = 16-bit bipolar microprocessor  (Turbosub)
- SOURCE: cpu\esrip\esrip.c


16.4   AM29323

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


16.5   CUBEQCPU (Rotate/Line/Sound CPU)

- 0.128u6            : Pointer-ified the Cube Quest CPUs cores [Aaron Giles].
- 0.127u4            : Aaron Giles fixed Cube Quest overlay scaling to cover the whole screen. Aaron Giles converted Simutrek-hacked laserdisc emulation to using the actual MCU from the game, which in turn hands off commands to the PR-8210 MCU. This is still not 100% but is pretty close at this point and achieves the correct behaviors in most cases.
- 0.127              : Added cpu\cubeqcpu\cubeqcpu.c/h. Phil Bennett, Joe Magiera and Warren Ondras added new driver for Cube Quest. This includes CPU cores for the three bitslice processors, as well as laserdisc support for the hacked laserdisc that was used to drive the games.
- NOTES: Implementation of the Simutrek Cube Quest bit-sliced CPU (AM2901-based).
- SOURCE: cpu\cubeqcpu\cubeqcpu.c



17.    Hyperstone

- 0.128u5            : Pointer-ified the Hyperstone core and removed all activecpu refs [Aaron Giles].
- 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.128u6          : Pointer-ified the MB86233 CPU core [Aaron Giles].
- 0.126u2          : TGP / Model 2 fixes [ElSemi]: TGP now correctly uses table roms (model1/2 updated accordingly). Removed FIFO hack on srallyc (game now runs). Added analog ports reading for model 2A/B/C. Fixed some loading instructions in the TGP. that fixes srallyc automatic transmission bug.
- 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.130              : Aaron Giles added function calls to replace the MIPS3 and PowerPC DRC's various CPU_SET_INFO bits.
- 0.129              : Aaron Giles removed HAS_PPC* in favor of a single HAS_POWERPC, and a single definition in cpu.mak for all PowerPC variants.
- 0.128u6            : Pointer-ified the PowerPC core [Aaron Giles].
- 0.125u7            : Aaron Giles changed DRC frontend to pass a pointer to the previous instruction when describing. Updated PowerPC frontend to approximately take into account branch and CR logic folding in timing computations.
- 0.125u6            : Created common virtual TLB managment module. Updated MIPS and PowerPC code to make use of it [Aaron Giles].
- 0.125u2            : Changed cpu\powerpc\ppcdrc.c to cpu\powerpc\ppcdrco.c.
- 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.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.125u5            : Nathan Woods fixed compilation error when neither HAS_PPC403GA nor HAS_PPC403GCX are defined.
- 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  PowerPC 602
- 0.129              : Aaron Giles hooked up DSA/ESA instructions for PowerPC 602 (as no-ops for now). Also hooked up PPC602 IBR. 'Tobe! Polystars' gets a little farther but crashes due to a TLB issue.
- 0.125u4            : Changed name 'PPC602' to 'PowerPC 602'.
- 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  PowerPC 603e/R
- 0.130              : Aaron Giles fixed bug that caused 64-bit PowerPC systems to fetch opcodes in the wrong order.
- 0.125u4            : Changed name 'PPC603' to 'PowerPC 603e' and 'PowerPC 603R'.
- 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  PowerPC 403GCX
- 0.125u4            : Changed name 'PPC403' to 'PowerPC 403GCX'.
- 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  PowerPC MPC8240
- 0.125u4            : Changed name 'MPC8240' to 'PowerPC MPC8240'.
- 0.112u1            : Ville Linde added support for the Motorola MPC8240 to the PowerPC core.
- SOURCE: cpu/powerpc/ppc.c + drivers/viper.c



19.17  Konami PowerPC based 3D games
- 0.125u7            : Aaron Giles added save state support to konppc module. Aaron Giles cleaned up system register access in Konami PowerPC games. Connected EEPROM in hornet driver (doesn't seem to affect much). Altered network IRQ timing to fix several problems. Most games are back to their previous "working" states. Guru added more complete README's for Konami PowerPC 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.2   PowerPC dynamic recompiler

- 0.125u9            : Aaron Giles fixed 64-bit writes in UML C back-end
- 0.125u7            : Aaron Giles added save state support to the PowerPC recompiler.
- 0.125u5            : PowerPC recompiler [Aaron Giles]: Fixed bug where a branch and link to the link register would overwrite the link register before fetching the target address. Updated to no longer explicitly specify flags. Added symbols for most common variables. Fixed bug in handling XER carry flag for subo forms. Simplified flag insertion logic for opcodeo forms. Rewrote lswi/stswi as subroutines. Made accesses to tempdata explicitly dword or qword. Fixed SRR0 when generating a syscall. Removed no longer necessary TESTs on extsb/w, rlwinm, rlwnm, rlwimi and cntlzw. Fixed bug where the SO flag was not being computed for compares. Fixed flag computations for mulhw/mulhwu/mullw. Fixed subtlety of shifts between 32 and 63 in srw/sraw. Fixed mffs/mtfsf to use FP registers. Fixed mtfsfi to use the immediate value properly. Now marking terminal count bit in DMA status register. Added support for 4xx protection registers via the MMU. Added TLBH, TLBU, and DEC to the list of registers in the debugger. Turned off "end of transfer" DMA signals in favor of "transfer count 0" signals; fixes memory-to-memory DMA in fiveside. Minor flags optimizations: * Broke CR into several individual bits of state and * Extracted the SO bit from XER into its own state. Cleaned up register tracking implementation. Fixed numerous errors and shortcomings in the tracking. Added support for removing unnecessary XER CA and CR0 computations. Updated UML logging to output new frontend statistics. Added basic cycle counts for longer instructions. Added penalty for polling timebase and decrementer registers. Fixed dependencies in cpu.mak. Reduced address bus width of 4xx series to 31 bits per the documentation. Fixed bug that would jump to incorrect PC after filling the TLB during a mismatch event. Added explicit address truncation to 31 bits for 4xx series. Added new PPCDRC_ACCURATE_SINGLES option, which removes the excessive (and very likely unecessary) extra rounding when performing the "fast" single-precision floating point ops. Fixed TLB filling for 4XX protection ranges. Fixed parameter ordering for masked reads/writes. Added detection of MMU enablement in 403GCX case. Fixed bug in protection bounds violation detection for 4XX. Changed SPU receive model to a push model; updated drivers accordingly. Added macros for setting the SPU transmit handler and sending bytes. Cleaned up ppc.h. Fixed lmw/stmw if rA is one of the loaded/stored registers. Removed unnecessary variables & structure members. Optimized for the XER and CR0 case where XER doesn't need an overflow calculation.
- 0.125u4            : Changed cpu\powerpc\ppcdrco.c to cpu\powerpc\ppccom.c. Added cpu\powerpc\ppcdrc.c + ppcfe.c/h. Universal recompiler: * Fixed frontend to handle opcode widths different from bus width. * Added several new opcodes: (D)GETFLGS - copies the UML flags to a destination operand and FDRNDS - rounds a double precision value to single precision. * Renamed several opcodes: (SETC   -> CARRY), (XTRACT -> ROLAND) and (INSERT -> ROLINS). * Consolidated the following opcodes: (LOAD?U -> LOAD), (LOAD?S -> LOADS), (STORE? -> STORE), (READ?U -> READ), (READ?M -> READM), (WRITE? -> WRITE), (WRITM? -> WRITEM), (SEXT?  -> SEXT), (FTOI?? -> FTOINT), (FFRI?  -> FFRINT) and (FFRF?  -> FFRFLT). * Removed some opcodes: FLAGS (can be done with GETFLGS/LOAD4/ROLINS), ZEXT (can be achieved with AND) and READ?S (can be achieved with READ/SEXT). * Updated C, x86, and x64 back-ends to support these opcode changes. * Updated disassembler to support these opcode changes. PowerPC dynamic recompiler [Aaron Giles]: Rewrote PowerPC implementation as a dynamic recompiler on top of the universal recompiler engine. * Wrote a front-end to analyze PowerPC code paths and register usage. * Wrote a common shared module with C implementations of tricky CPU behaviors. * Added separate CPU types for the variants supported, instead of relying on a hidden model enum. * Rewrote the serial port emulation for the 4xx series to be more accurate and not rely on separate DMA handlers. * Rewrote the MMU handling to implement a software TLB that faults in pages and handles changed bits appropriately. * Implemented emulation of the PowerPC 603's software TLB, which allows the model 3 games to run without a hack to disable the MMU. Aaron Giles updated the PowerPC disassembler to share constants with the rest of the core, and to more aggressively use simplified mnemonics, especially for branches.
- 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.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            : 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. 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. 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\powerpc\ppcdrc.c + cpu\powerpc\ppcfe.c



19.3   DRC - Dynamic Re-Compiling

- 0.129u2            : DRC frontends must now do their own opcode fetching unfortunately. Updated all DRC cores to do this. Also tweaked a few oddities in the SH2 DRC [Aaron Giles].
- 0.126u5            : R. Belmont fixed Cool Riders crash with DRC, now hangs waiting for impossible conditions again.
- 0.126u1            : Aaron Giles fixed edge case in the DRC front-end that would incorrectly tag the end of a sequence as "return to start" even if the last instruction did not abet the starting instruction.
- 0.125u7            : DRC fixes [Aaron Giles]: Fixed WRITEM opcode on 64-bit to call through memory instead of directly. Solves assertions with gcc 4.3 and 64-bit linux. Fixed DCMP opcode on the 32-bit back-end. Fixed LZCNT opcode in x86 and x64 back-ends. Added support for flags in LZCNT and BSWAP opcodes on x86 and x64 back-ends. Aaron Giles changed DRC frontend to pass a pointer to the previous instruction when describing. Updated PowerPC frontend to approximately take into account branch and CR logic folding in timing computations.
- 0.125u6            : UML [Aaron Giles]: Reactivated back-end validation mechanism. Added back-end validation for ADD/SUB/MUL/DIV/CMP forms. Fixed several errors in dealing with more obscure flag combinations.
- 0.125u5            : Removed cpu\drcumld.c/h. DRC UML changes [Aaron Giles]: Separated conditions and flags into two separate fields. Added more extensive per-opcode information. Made validation more thorough using the extended information. Disabled back-end validation for now until it can be revisited using the new tables. Changed GETFLGS encoding so that the mask is in parameter 2 instead of the flags field. Wrote new disassembler based on enhanced opcode info structure. Moved disassembler into drcuml.c and removed old code. Extended disassembler buffer sizes to at least 256 bytes. Removed explicit flag requests from the shorthand opcodes. Added optimization function to drcuml which is called at block end. Added logic to compute the necessary flags based on upcoming opcodes and only select those flags which are required. Added NOP opcode. Added logic to simplify opcodes as much as possible at the UML layer. Removed similar logic in the x86 and x64 back-ends. Added stricter parameter validation for registers and mapvars. Improved disassembly output. Added simple symbol table to the UML for improved disassembly. Changed optional disassembler cache parameter to a drcuml object. Fixed STORE opcode description to allow immediate source operands. DRC frontend changes [Aaron Giles]: Changed from tracking "live" registers to tracking "necessary" registers. Genericized register tracking to be more flexible. Added previous instruction pointer to opcode descriptions.
- 0.125u3            : DRC frontend changes [Aaron Giles]: Fixed bug in handling edge case with the PC near the 0 or ~0. Added new flag to tag privileged instructions. UML updates [Aaron Giles]: Added new opcode SETC to set the carry flag from a source bit. Added new opcode BSWAP to swap bytes within a value. Updated C, x86, x64 back-ends to support the new opcodes. Updated disassembler to support the new opcodes.
- 0.125u2            : Universal DRC system updates and improvements [Aaron Giles]: UML: * Added back-end validation mechanism, and a handful of tests as examples. This will be expanded in the future. * Added several new opcodes: SAVE dumps the entire virtual machine state to a struct, RESTORE applies the data in a struct to the live state, LZCNT counts leading zeros in an operand, XTRACT extracts a bitfield to another register (rlwinm) and INSERT inserts a bitfield into a register (rlwimi). * Added new back-end function get_info() which returns information from the back-end about how many actual registers will be mapped. x86 back-end: * Implemented all new opcodes. * Implemented get_info() function. * Fixed several bugs relating to shifts/rotates and optimizing out cases incorrectly. x64 back-end: * Implemented all new opcodes. * Implemented get_info() function. * Added defines for new Penryn opcodes to x86emit.h. * Added support for ROUNDSS and ROUNDSD on Penryn architectures. This hasn't been tested. If you have a Penryn-based system, give it a try. * Fixed several bugs relating to shifts/rotates and optimizing out cases incorrectly. C back-end: * Implemented all new opcodes. * Implemented get_info() function. * Cleaned up operand sizing. * Fixed several errors that made it not work on bigendian systems. MIPS DRC: * Added some instrumentation for the MMU. To enable it, turn on PRINTF_MMU at the top of the file. * Fixed front-end so that virtual no-op instructions are still targeted as branch targets. * Fixed front-end to mark the beginning of each sequence as needing TLB validation, since any sequence can be jumped to from anywhere. * Redid the MIPS3 TLB implementation. Fixed the exception vector and type handling. Changed the bitfields to directly map from the MIPS TLB format. Added distinction between TLB fill and TLB valid/modified exceptions. * Added separate modes for user, supervisor, and kernel modes. Each mode does proper verification of addresses now and generates address errors for invalid accesses. * Fixed several bugs in the TLB implementation; not everything works yet but it's a lot closer. * Made COP0 access checking mandatory in non-kernel modes. * Fixed several crashes when recompiling virtual no-ops. * Fixed TLB bug where entries for virtual address 0 were present by default. * Fixed bug in the map variable implementation that would sometimes result in incorrectly recovered values.* Implemented IDT instructions. All invalid instruction asserts are now runtime-only. * Added support to map a few common registers to machine registers if the machine supports it. Currently only x64 on Windows has enough free registers to do so, though PowerPC will almost certainly be able to take advantage of this. Gives a minor speedup. * Updated to use INSERT and XTRACT where appropriate. * Cleaned up register usage to free up one machine register for x64 on Linux.
- 0.125u1            : Added cpu\drcbec.c, drcbeut.c/h, drcbex64.c, drcbex86.c, drccache.c/h, drcuml.c/h, drcumld.c/h and drcumlsh.h. New universal dynamic recompiler system [Aaron Giles]: The central module is drcuml.c, which defines a universal machine language syntax that can be generated by a frontend recompiler and then retargeted via a generic backend interface to any of a number of different architectures. A disassembler for the UML is also included to allow examination of the generated UML code. Currently supported backend architectures include 32-bit x86, 64-bit x86, and a platform-neutral interpreted C backend that can be used as a fallback for platforms without native support. The C backend also performs additional validation to ensure assumptions are met. Along with the new architecture is a new MIPS III/IV recompiler frontend. This frontend has been rewritten from the old x64-specific recompiler to generate UML opcodes instead. This means that the single recompiler can be used to target multiple backend architectures and should in theory produce identical results across all of them. The old 32-bit and 64-bit MIPS recompilers are now officially retired. The new system provides similar performance (within 5% generally) to the old system and has similar compatibility. The only currently known issues are some problems with the two Gauntlet 3D games.


19.31  x86/x64
- 0.125u9            : Aaron Giles fixed incorrect assumption in the x86/x64 implementation of HASHJMP that the base table for a mode will always be allocated when a fixed mode is first used.
- 0.125u5            : x86/x64 back-ends [Aaron Giles]: Added flag support to SEXT, ROLAND, ROLINS, LZCNT opcodes. Fixed bug where sometimes the flags would be corrupted; in particular, we always clobbered the flags for the subfze instruction, which broke the nbapbp camera and some other things. Fixed DIVS/DIVU opcode so they properly compute SZ flags when requested; fixes camera wackiness in nbapbp. Added a "hop" around the prolog of the HANDLE opcode to allow fall-through. Redesigned x86 stack management to keep the stack at the same 16-byte alignment. Fixed adc/sbb so that they don't optimize out ever. Fixed detection of special and/or/xor cases. Fixed GETFLGS opcode so that it doesn't return anything other than requested flags. Changed LZCNT/BSWAP to be more flexible in register selection.



19.4   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.
- SOURCE: cpu\powerpc\ppc_mem.c

19.5   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.128u4            : Pointer work on SE3208 [David Haywood].
- 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.128u6            : Pointer-ified the APEXC CPU core [Aaron Giles].
- 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            : Removed Pong, gensync\gensync.c and gensyncd.c/h 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            : Added cpu\gensync\gensync.c/h and gensyncd.c. 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.128u6            : Pointer-ified the CP1610 CPU core [Aaron Giles].
- 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.
- 0.37b7             : Added cpu\cp1600\cp1600.c/h and 1600dasm.c.
- NOTES: General Instrument CP1600 emulator by Frank Palazzolo
- SOURCE: cpu\cp1610\cp1610.c



21.31  SSP1601

- 0.128u4            : Converted ssp1601 to pointers (still works, tested virtua racing genesis) [Curt Coder].
- 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\ssp1601\ssp1601.c



21.4   CDP1802

- 0.129u1            : CDP1802 CPU core [Curt Coder]: Improved register layout. Randomized register contents on initialization. Converted the CDP1802 CPU core to use a state table.
- 0.128u5            : Curt Coder normalized CDP1802 state variables to 'cpustate'.
- 0.128u4            : Pointerized and refactored the CDP1802 core to use the new memory functions [Curt Coder].
- 0.125u1            : Curt Coder added memory address parameter to CDP1802 DMA callbacks and a macro for the CPU interface.
- 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.
- 0.37b7             : Added cpu\cdp1802\cdp1802.c/h, disasm.c and table.c.
- 23rd August    2000: Peter Trauner added a Cosmac CDP1802 CPU core.
- GAMES: Cidelsa
- SOURCE: cpu\cdp1802\cdp1802.c



21.5   Fairchild 3850

- 0.129              : Moved cpu\f8\f3853.c/h to machine\f3853.c/h. Wilbert Pol changed the F3853 implementation into a device.
- 0.128u7            : Wilbert Pol added running_machine parameters to the f3853 callbacks.
- 0.128u6            : Pointer-ified the F8 core [Atari Ace]. Nathan Woods re-synced f3853 core with MESS.
- 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.
- 0.37b6             : Added cpu\f8\f8.c/h 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

- 0.35b4             : Added machine\kabuki.c
- 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.127u7            : Aaron Giles optimized ST-0016 RAM tile behavior to lazy decode the graphics, giving a big speed boost to some of the mahjong games.
- 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

-  1st June      2008: Charles MacDonald - V25 research: There are a number of instructions which delay interrupt and exception processing, allowing one more instruction to be executed before the interrupt is taken. For the prefixes, this prevents an interrupt from being taken after the prefix byte has been fetched but before the instruction it applies to has been executed. Likewise for segment register loads, if an interrupt occurred after SS was changed, SP would be invalid. By delaying interrupts the following types of sequences become uninterruptible. It seems less important to have DS and ES register loads delay interrupts as well, I did not expect this behavior. I have been looking at the MCU code for other games and it seems that they use similar, if not identical instruction encodings, despite using differently labeled MCUs. V-Five in particular seems to match the Knuckle Bash opcodes quite closely, and when/if I can get Knuckle Bash decrypted, I'll see how much of V-Five can be decrypted.
- 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.
- 12th April     2008: Charles MacDonald - I recently acquired a Toaplan "Knuckle Bash" PCB. It's a fairly impressive system, based around a custom graphics chip which displays three tiled background layers and two 512x512 12-bit framebuffers for double buffered sprites. It has a 68HC000 running at 16 MHz that handles all the game related tasks, and a V25S MCU that manages inputs, sound effects, and music playback. The music for this game is quite good and definitely a notch above the rest. A lot of other Toaplan games use the same graphics chip, so I'm intending to run tests on it and get all the timing and other details worked out. The V25S microcontroller is a 80186 clone manufactured by NEC. Unlike the V25 it has no usable internal ROM and no 8080 emulation mode, the latter of which has been modified to add a new 'secure' operating mode. In secure mode a lookup table translates opcodes fetched from memory with their V25S equivalents. This allows the opcode-to-instruction mapping to be changed as the customer (Toaplan) sees fit, making the program code unusable unless the table contents are known. Luckily operands and data are not encrypted, and examination of the operands such as the ModR/M byte can reveal what category of instructions a particular opcode might fit in to. NEC intended for the V25S to be used as a drop-in replacement for the V25, to accomplish this it uses one of the unused V25 pins as a mode select input. When tied high or floating (due to an internal pull-up resistor) the CPU runs in normal mode, where the lookup table is bypassed and opcodes are processed normally. When tied low, the CPU is in secure mode and the lookup table is utilized. This pin is sampled during a reset, interrupt, or exception, and bit 15 of the PSW can be modified through select instructions to change the operating mode regardless of the pin state as well. These features allow a V25S to start in normal mode and selectively execute encrypted programs while still interacting with a unencrypted BIOS, operating system, and device drivers, or vice-versa. I modified the Knuckle Bash board to start the V25S in normal mode, and developed a program that sets the MCU to a known state and enters secure mode with the instruction trap feature enabled. This forces just one encrypted instruction to be executed before control is passed back to my unencrypted code, at which point the potentially modified state of the MCU is saved and examined. The behavior of all encrypted opcodes (except BRKS which sets up an unrecoverable state) can therefore be examined. I can see things like what data was pushed or popped from the stack, which registers were loaded, exchanged, or modified, and which instructions triggered an I/O or floating point exception. A lot of information can be gathered about the encrypted instructions, which narrows down or completely identifies which unencrypted instructions they map to. Best of all this technique should work for any V25S based system, such as the other Toaplan games. I'm looking forward to trying it on my Golden Axe 2 security board to see how effective it is after finishing with Knuckle Bash, though right now it's too early to give any indication of progress. Toaplan did an excellent job with the protection. The program ROM is filled with valid Z80 code and garbage data to throw off statistical analysis of the ROM, such as observing the frequency of occurence for particular bytes and byte sequences. The MCU has no manufacturer marking and has ambiguous names printed on it like "NITRO" and "DASH". Furthermore, the lookup table maps many opcodes to the same instructions so certain easily identifiable instructions can simply never be executed, increasing the number of potential matches any encrypted instruction might have. If this technique is applicable to the V35S, we'll have to see what Irem did with their games.
- 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.128u4            : Pointer-ified the M377xx [R. Belmont].
- 0.127u2            : M377xx [R. Belmont]: 8-bit I/O port reads no longer cause bogus reads of neighboring ports.
- 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.129u1            : Atari Ace removed some long dead state save functions in M37710 core.
- 0.128u4            : Pointer-ified the M377xx [R. Belmont].
- 0.127u2            : M377xx [R. Belmont]: 8-bit I/O port reads no longer cause bogus reads of neighboring ports.
- 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.128u6            : Pointer-ified the SC61860 CPU core [Aaron Giles].
- 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.
- 0.37b4             : Added cpu\sc61860\sc61860.c/h, disasm.c, ops.c, readpc.c, sc.h and table.c.
- NOTES: The Sharp SC61860 is a CPU Sharp in pocket computers
- SOURCE: cpu\sc61860\sc61860.c



21.E   LH5801

- 0.128u6            : Pointer-ified the LH5801 CPU core [Aaron Giles].
- 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.128u6            : Pointer-ified the Saturn CPU core [Aaron Giles].
- 0.125u2            : Removed cpu\saturn\sat.h. Antoine Mine corrected several bugs in the emulation of the Saturn CPU. These corrections are needed to make new HP48 drivers (to be submitted to MESS imminently) work.
- 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.128u6            : Pointer-ified the PDP1/TX0 CPU core [Wilbert Pol].
- 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.
- 0.36b4             : Added cpu\pdp1\pdp1.c/h 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



21.K   Sharp LR35902

- 0.128u6            : Pointer-ified the LR35902 CPU core [Aaron Giles].
- 0.125u6            : Added cpu\lr35902\lr35902.c/h, lr35902d.c, opc_cb.h and opc_main.h. Removed cpu\z80gb\z80gb.c, z80gbd.c, opc_cb.h, opc_main.h, z80gb.h. Wilbert Pol renamed "Nintendo z80gb" CPU core to "Sharp LR35902".
- 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.
- 0.36b14            : Added cpu\z80gb\z80gb.c/h, z80gbd.c, opc_main.h, opc_cb.h and daa_tab.h.
- SOURCE: cpu\lr35902\lr35902.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
  2.75  D49307

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

  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   OKI6258
  9.4   OKI6295
  9.5   OKI6376
  9.6   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   Sega/Yamaha 315-5560

 14.    Seta
 14.1   X1-010
 14.2   ST0016
 14.3   ST0026

 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
 24.B   SNK Wave

 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
 26.D   Digitalker

 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  RCA 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
 29.7   09R81P

 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.129u4            : Removed emu\sndintrf.c. Aaron Giles converted all sound chips into proper devices. Merged the sound chip interface into the device interface, removing any differences (such as the whole ALIASing concept). Aaron Giles modified every sound chip in the following ways: Updated to match the device interface. Reduced read/write handlers down to the minimal number. Added the use of get_safe_token() for ensuring correctness. Other minor cleanup. Aaron Giles vastly simplified the sound interfaces, removing the ghastly sndti_* business and moving everyone over to using tags for sound identity. sndintrf, like cpuintrf, is now just a header file with no implementation. Modified each and every driver that references a sound chip [Aaron Giles]: All memory maps explicitly reference the targeted device via AM_DEVREAD/AM_DEVWRITE/AM_DEVREADWRITE. 16-bit and 32-bit accesses to 8-bit chips no longer use trampoline functions but instead use the 8-bit AM_DEVREAD/WRITE macros. All references to sound chips are now done via tags. Note that these changes are brute force, not optimal; in many cases drivers should grab pointers to devices in MACHINE_START and stash them away. Aaron Giles added the ability for devices to have their own custom inline config management. This was primarily added to allow for sound routes to be supported in a way that is compatible with the current driver structure. A device can now define a DEVICE_CUSTOM_CONFIG callback which is called whenever one of the MCONFIG_TOKEN_DEVICE_CONFIG_CUSTOM_* tokens is encountered. A special token MCONFIG_TOKEN_DEVICE_CONFIG_CUSTOM_FREE is defined to clean up memory allocated and/or reset the custom configuration, and is called when the device is torn down to allow for memory cleanup.
- 0.129u2            : Sound cores no longer allocate their own tokens. Instead they return a new integer value indicating the size of token they want, and the core allocates it for them. This mirrors the standard device behavior [Aaron Giles]. Aaron Giles removed redundant config parameter from SND_START.
- 0.129u1            : Atari Ace removed the sndindex parameter from SND_START, in favor of using the device pointer or tag as appropriate. Atari Ace made the treatment of SOUND_xxx the same as that of CPU_xxx. That is, they are function pointers to the SND_GET_INFO routine for the sound. Dirk Best removed several useless occurrences of "#define INLINE" in CPU and sound cores.
- 0.129              : Atari Ace updated all the sound core header files to declare their SND_GET_INFO functions, which will be needed once the sound cores become proper devices. It also makes a handful of other header declaration fixes in emu/sound, and makes one SND_RESET routine static. Note: votrax.h is a new include file altogether. Aaron Giles changed all CPU and sound cores to use memory_find_address_space() instead of cpu_get_address_space(). The former is reliable even during early initialization when the CPU cores generally need it.
- 0.128u7            : Aaron Giles cleaned up device and sound interfaces to match the CPU interfaces when handling strings. Namely, the generic get_info functions allocate a temporary string and the device in question copies its string to the target, instead of assigning a const char *. Updated all device and sound cores to operate this way.
- 0.128u6            : Atari Ace removed remaining deprecat.h references from the sound cores.
- 0.128u5            : Atari Ace furthered the process of aligning the sound cores with the recent cpu core changes. Added a fake device implementation similar to the one the cpu cores are using. Made some interface adjustments aligned to 128u4 (i.e. adding snd_class_header, adding get_ to various getter functions). The primary benefit of this change is the removal of "deprecat.h" from 23 sound cores. Also adjusted ui.c to stop calling sndnum_clock and access the clock data similarly to how it does the cpu clock data. Note from Aaron: Further changes to the sound interfaces will be kept to a minimum until the CPUs are sorted out. Aaron Giles extended the fake sound devices to have more populated fields. Modified sound cores to use tags from the devices and simplified the start function. Aaron Giles renumbered CPU and sound get/set info constants to align with the device constants, and shared values where they were perfectly aligned. Aaron Giles set the type field in the fake device_configs for CPU and sound chips to a get_info stub which calls through to the CPU and sound specific get_info functions. This means the device_get_info() functions work for CPU and sound cores, even in their fake state. Aaron Giles changed device information getters from device_info() to device_get_info() to match the CPU and sound macros.
- 0.128u4            : Defined macros for standard sound core functions and updated all sound cores to use them [Atari Ace].
- 0.127u3            : CPUs, sound chips, devices and ROM-regions which are specified by devices now have their tags auto-prefixed with the device's tag. This allows for multiple instances to be present. For example, the PR-8210 laserdisc player has a CPU with a tag of "pr8210". When it is included as a device by a driver, the driver may tag the device "laserdisc". The resulting final CPU tag name will be "laserdisc:pr8210". Also updated the debugger expression engine to support names with embedded colons [Aaron Giles]. Aaron Giles added checks to ensure that tags used for CPUs, sound chips, regions, and devices follow some basic rules: they should be less than 15 characters long, be all lower-case, and only contain letters, numbers, underscores, or dots (no spaces). This is to ensure that they can be used properly in debugger expressions and don't get too long or unwieldy to type (even 15 chars is rather long). Fixed up all tags in the system that failed these checks.
- 0.127u2            : Aaron Giles changed refreshspeed target to 0.25Hz below rate provided, in order to guarantee that inexact timings do not lead to sound stuttering.
- 0.127              : Oliver Stoenberg removed duplicated TMS5110 entry in sound.mak.
- 0.126u5            : Oliver Stoeneberg cleaned up and grouped the sound chip entries based on sound.mak. Derrick Renaud updated structure and naming conventions of sound and CPU cores to match core conventions.
- 0.126u3            : Aaron Giles introduced a new auto-binding mechanism for sound cores. This works similarly to the CPU binding. Each sound core that requires a memory region now auto-binds to the region with the same tag as the sound core. In almost all cases, this allowed for the removal of the explicit region item in the sound configuration, which in turn allowed for many sound configurations to removed altogether.
- 0.126u2            : Aaron Giles removed MDRV_SOUND_ADD. Renamed MDRV_SOUND_ADD_TAG to MDRV_SOUND_ADD. All sound chips must now include a tag. Changed all existing drivers to define a unique tag for each sound chip.
- 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.
- 0.35b9             : Removed sndhrdw\generic.c/h.
- 0.31               : Removed sndhrdw\waveform.c/h.
- 0.30               : Added sndhrdw\waveform.c/h.
- SOURCE: sndintrf.c



S1.1   Streams

- 0.128u7            : Atari Ace modified the parameters of the stream_update_func callback. As part of this work, macro-ized all the callbacks to STREAM_UPDATE, and added the sound device as a parameter.
- 0.128u6            : Atari Ace added the sound device to the parameters passed to stream_create so that the global Machine can be removed from streams.c.
- 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.35b13            : Removed sound\exvolume.c/h.
- 0.35b6             : Added sndhrdw\exvolume.c/h.
- 0.34b4             : Added sndhrdw\streams.c/h. 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.
- 0.35b13            : Added sound\mixer.c/h.



S1.3   Discrete sound

- 0.129u3            : Several discrete sound refinements, mainly targeted at Mario Bros [couriersud]: Use formula derived from figures 2 and 3 in LS624 datasheet. Coefficients were calculated using least square approximation. This approach gives a bit better audible results compared to the prior approach. Fixed energy calculation for LS624. Use energy values as input for XOR. This seems to better reflect the superimposition of the two signals. On the long term, both LS629 and the XOR need to be converted into a custom module to properly model mixing if the two frequencies are close to each other. Adjusted C41 to 60% for skid sound.
- 0.128u4            : abc_step and abc_reset now declared as DISCRETE_STEP( abc ) and DISCRETE_RESET( abc ) [Couriersud]. Fixed state save in discrete sound [Couriersud]: sndindex now considered as well in state save. Expose discrete_sound_n_r(void *chip, ...) to enable accessing multiple discrete sound cores.
- 0.128u2            : More Discrete module optimizations [Derrick Renaud]: Added optimized custom mixer to Donkey Kong. R. Belmont fixed GCC 4.3 "array bounds exceeded" error in disc_flt.c.
- 0.127u2            : Optimized DISCRETE_RCDISC_MODULATED. Added X_TALs to circus. Optimized DISCRETE_RCINTEGRATE and DISCRETE_555_ASTABLE. Optimized DISCRETE_555_ASTABLE_CV and DISCRETE_MIXER. Optimized DISCRETE_555_CC. The 555 and mixer changes also speed up just about every current discrete game [Derrick Renaud]. Derrick Renaud started removing extraneous enable lines from the discrete modules. Most modules are always enabled anyways.
- 0.127u1            : Derrick Renaud cleaned up the discrete code and fixed discrete logging. 
- 0.126u5            : Changed includes\rescap.h to machine\rescap.h.
- 0.126u4            : Minor optimization to the DISCRETE_INPUT modules. The node output is now calculated when a discrete_sound_w() is called instead of each step in the simulation. Also removed the Enable line from the DISCRETE_ADJUSTMENT modules. They should never be disabled [Derrick Renaud]. Discrete sound core optimizations [Couriersud]: Moved a couple of exp(x) from _step into _reset where appropriate. Use tabulated function values for the transfer function in DSS_INVERTER_OSC. Couriersud added module profiling to discrete sound core: Added DISCRETE_PROFILING macro to discrete.h. Upon discrete_stop, the worst performing modules will be listed.
- 0.125u4            : Discrete sound update [Couriersud]: Added NODE_RELATIVE(NODE, offset) macro to discrete.h. Fixed asteroid.c, canyon.c, skydiver.c and tank8.c to use this macro instead of adding directly to the node.
- 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 includes\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.34b4             : Removed sndhrdw\rcfilter.c.
- 0.34b3             : Added sndhrdw\rcfilter.c.
- 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.
- 0.36RC1            : Added sound\speaker.c/h.
- 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.129u4            : Removed sound\custom.c/h. Aaron Giles removed the custom sound device. The additional work to just make custom sound cases into full devices is minimal, so Aaron just converted them all over to be actual devices.
- 0.128u6            : Introduced function macros for CUSTOM_{START,STOP,RESET}. Pushed the running_machine * passing through these functions. In other locations added "running_machine *machine = Machine" to the top of functions to isolate the dependencies [Atari Ace].
- 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.128u6            : Introduced function macros for SAMPLES_START. Pushed the running_machine * passing through these functions. In other locations added "running_machine *machine = Machine" to the top of functions to isolate the dependencies [Atari Ace].
- 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               : Added sndhrdw\samples.c/h. 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               : Added adpcm.c/h. 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.129u5            : Nathan Woods added ATTR_NOTNULL to DAC sound calls.
- 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               : Added sndhrdw\dac.c/h. 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)

S2.75  D49307
- PCB: HITACHI DF1 D49307, Three-Channel 8-bit D/A Converter (SuperKaneko-NovaSystem)


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            : Added sound\sn76477.c/h. 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.22  T6W28
- 0.131: Added emu\sound\t6w28.c/h. Wilbert Pol added T6W28 sound core (SNK(?) custom SN76489a clone).
- SOURCE: sound\t6w28.c


S3.3   SN76496

- 0.125u5            : Additional documentation in the SN76496 core [Lord Nightmare].
- 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.36b15            : Removed sound\sn76496u.c.
- 0.34b4             : Added sndhrdw\sn76496u.c.
- 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               : Added sndhrdw\sn76496.c/h. 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            : Added sound\tms36xx.c/h. 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)




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.
- 0.35b10            : Added sound\tiasound.c/h and tiaintf.c/h.
- 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             : Removed sndhrdw\pokyintf.c/h. Juergen Buchmueller improved the Pokey emulation.
- 0.30               : Removed sndhrdw\8910intf.c. 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               : Added sndhrdw\pokyintf.c/h. 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               : Added sndhrdw\8910intf.c/h. 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               : Added sndhrdw\pokey.c/h and pokey.txt. 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.
- 0.36b1             : Changed sndhrdw\ataraud2.c/h to sndhrdw\atarijsa.c/h.
- 0.35b11            : Added sndhrdw\ataraud2.c/h.
- SOURCE: audio\atarijsa.c
- 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.126u5            : More FM OPN fixes [Eke, R. Belmont]: Pass chip type around and restore Jarek's original behavior for YM2203/YM2610. Always recalculate attack rate in set_ar_ksr, fixes Megadrive/Genesis "Batman & Robin".
- 0.126u4            : Backported a bunch of FM OPN (YM2608/2612) fixes from Genesis Plus GX. All of this was verified on real hardware [Eke-Eke, Nemesis, Alone Coder, AamirM]: Implemented PG overflow, aka "detune bug" (Ariel, Comix Zone, Shaq Fu, Spiderman...). Fixed SSG-EG support. Modified EG rates and frequency. Fixed EG attenuation level on KEY ON (Ecco 2 splash sound). Fixed LFO phase update for CH3 special mode (Warlock, Alladin).
- 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.36b13            : Removed sound\fmext.c.
- 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.
- 0.36b1             : Added sound\fmopl.c/h.
- 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             : Added sndhrdw\fmext.c. 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               : Added sndhrdw\fm.c/h. 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.129u5            : Phil Bennett fixed distorted YM2151 sound.
- 0.126u4            : Jarek Burczynski forced synchronization (stream_update()) before the YM2151 status is actually read.
- 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               : Added sndhrdw\ym2151.c/h. New YM2151 emulator [Jarek Burczynski]. Tatsuyuki Satoh improved YM2203 and YM2151 emulator, and DAC interface, with 16 bit samples support.
- 0.30               : Added sndhrdw\2151intf.c/h. 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.126u5            : More FM OPN fixes [Eke, R. Belmont]: Pass chip type around and restore Jarek's original behavior for YM2203/YM2610. Always recalculate attack rate in set_ar_ksr, fixes Megadrive/Genesis "Batman & Robin".
- 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.35b11            : Added sound\2203intf.h. Removed sound\psgintf.h.
- 0.35b9             : Removed sndhrdw\2203intf.h.
- 0.35b6             : Removed sndhrdw\psgintf.c.
- 0.35b5             : Added sndhrdw\2203intf.c.
- 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               : Added sndhrdw\2203intf.h and psgintf.c/h. 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.25               : Removed sndhrdw\ym2203.h.
- 0.23               : Added sndhrdw\ym2203.h. "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             : Added sndhrdw\ym2413.c and 2413intf.h. 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.128u2            : YM2608/2612 update [Eke-Eke, Nemesis]: Applied latest fixes/discoveries.
- 0.126u4            : Backported a bunch of FM OPN (YM2608/2612) fixes from Genesis Plus GX. All of this was verified on real hardware [Eke-Eke, Nemesis, Alone Coder, AamirM]: Implemented PG overflow, aka "detune bug" (Ariel, Comix Zone, Shaq Fu, Spiderman...). Fixed SSG-EG support. Modified EG rates and frequency. Fixed EG attenuation level on KEY ON (Ecco 2 splash sound). Fixed LFO phase update for CH3 special mode (Warlock, Alladin).
- 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.
- 0.35b11            : Added sound\2608intf.c/h. Removed sound\psgintf.h.
- 12th April     1999: Tatsuyuki Satoh has updated the FM engine, adding preliminary support for YM-2608.
- 0.35b6             : Removed sndhrdw\psgintf.c.
- 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.126u5            : More FM OPN fixes [Eke, R. Belmont]: Pass chip type around and restore Jarek's original behavior for YM2203/YM2610. Always recalculate attack rate in set_ar_ksr, fixes Megadrive/Genesis "Batman & Robin".
- 0.122u1            : Phil 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.35b11            : Removed sound\ym2610.h.
- 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             : Removed sndhrdw\ym2610.c. 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             : Added sndhrdw\2610intf.c/h. 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.
- 0.34b6             : Added sndhrdw\ym2610.c/h.
- 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.128u2            : YM2608/2612 update [Eke-Eke, Nemesis]: Applied latest fixes/discoveries.
- 0.127              : R. Belmont reduced YM2612 DAC level relative to FM. This better matches real hardware.
- 0.126u4            : Backported a bunch of FM OPN (YM2608/2612) fixes from Genesis Plus GX. All of this was verified on real hardware [Eke-Eke, Nemesis, Alone Coder, AamirM]: Implemented PG overflow, aka "detune bug" (Ariel, Comix Zone, Shaq Fu, Spiderman...). Fixed SSG-EG support. Modified EG rates and frequency. Fixed EG attenuation level on KEY ON (Ecco 2 splash sound). Fixed LFO phase update for CH3 special mode (Warlock, Alladin).
- 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).
- 0.35b11            : Removed sound\psgintf.h.
- 0.35b6             : Added sndhrdw\2612intf.c/h. Removed sndhrdw\psgintf.c.
- 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.129u4            : Added sound\3526intf.c/h.
- 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.36b13            : Removed sound\ym3812.c/h.
- 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             : Added sndhrdw\ym3812.h and 3812intf.c. 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].
- 0.31               : Added sndhrdw\ym3812.c and 3812intf.h.
- 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.128u6            : R. Belmont re-ordered SCSP init to fix crash.
- 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.128u3            : AICA update [R. Belmont, Deunan Knute, kingshriek]: Fixed missing instruments in DTPK driver games.
- 0.128u1            : Kingshriek fixed AICA sample addressing for the full 8 MB.
- 0.126u3            : AICA updates [Deunan Knute, ajax16384, R. Belmont]: Fixed ADPCM decoder to remove bad optimization and match YMZ280B. DC offset is fixed and output quality is higher. Improved handling of slot monitor and timers B and C. Simplified interpolation code.
- 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.123u6            : Zsolt Vasvari fixed AICA memory leak.
- 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.130u2            : Cs9ph7Rg0 added ymz280b_r to E-Jan Sakurasou memory map to prevent musics to stop while playing.
- 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             : Added sound\ymz280b.c/h. 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.130u1            : AY-3-8910 improvements [couriersud]: Fixed Gyruss audio regression. Measured RU and RD on AY-3-8910. Modelled ZX Spectrum audio circuit in SwitcherCAD and derived resistor values for AY-3-8910.
- 0.128u5            : Aaron Giles fixed wrong audio tempo in some drivers with Z80/AY8910 (ID 02691)
- 0.127u5            : Couriersud fixed Leland AY8910/12 output combining.
- 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            : Removed sound\ay8910u.c. 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.35b9             : Removed sndhrdw\8910intf.h.
- 0.35b2             : Zsolt Vasvari added Centipede (bootleg with AY8910 instead of Pokey).
- 0.34b4             : Changed sndhrdw\psg.c/h and psg.txt to sndhrdw\ay8910.c/h and ay8910u.c
- 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.129u4            : Added sound\8950intf.c/h.
- 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.
- 0.36b11            : Added sound\ymdeltat.c/h.
- 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             : Added sndhrdw\astrocde.c/h. 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.
- 27th September 1999: Aaron Giles sent in a Bally/Sente driver update with Name That Tune and several Trivial Pursuit versions.
- 0.36b5             : Added sound\cem3394.c/h.
- 12th September 1999: Aaron Giles sent in a fairly minor update to the Bally/Sente driver, with 8-bit sound fix.
- 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.
- 0.35b4             : Added exidy440.c driver and sndhrdw\exidy440.c.
- 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.31               : Added sndhrdw\namco.c/h.
- 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            : Phil 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             : Added sound\c140.c/h. 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.127u3            : C352 cleanup [Olivier Galibert]: Removed an unused volume table dating from before the volume was (correctly) implemented as linear.
- 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.128u2            : Phil Bennett fixed MSM5205 ADPCM and sound communications in Ashita no Joe/Success Joe.
- 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 sound\msm5205.c/h. 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.
- 0.35b12            : Added sndhrdw\irem.h.
- 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   OKI6258
- 0.128u4: Added Oki MSM6258 sound core [Barry Rodewald]. Added sound\okim6258.c/h.
- SOURCE: sound\okim6258.c


S9.4   OKI6295

- 0.129u6            : Aaron Giles fixed noticeable static in OKI 6295 audio.
- 0.129u1            : Phil Bennett updated OKIM6295 volume table to reflect actual chip behaviour. Removed "contact MAMEDEV" message.
- 0.128u6            : Relaxed the OKI 6295 command validity check [Nicola Salmoria].
- 0.128u5            : Nicola Salmoria changed OKI 6295 to use a reasonable volume table derived from the manual. Added popmessages to notify of invalid commands so we can investigate them if some game uses them. It should also be noted that many games using this chip are clipping at the moment. This is something that might date back to when sound mixing was upgraded to 32-bit. It is sensible for the 6295 emulator to output at this level because it ensures that bits of precision are not lost, so the mixing levels in the drivers should be adjusted to avoid clipping.
- 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.5   OKI6376

- 0.129u2            : Mirko Buffoni fixed clamping to 12 bit range to Okim6376 and adjusted volume attenuation accordingly.
- 0.129u1            : Added sound\okim6376.c/h. Added OKIM6376 emulation ADPCM speech synthesizer [Mirko Buffoni, Phil Bennett]. Added OKIM6376 sound emulation to High Video games [Mirko Buffoni]: Removed GAME_NO_SOUND from newmcard, brasil and fashion. Sound frequency may be incorrect.
- GAMES: New Magic Card (New High Video 19??), Bra$il (New High Video? 2000)
- SOURCE: sound\okim6376.c



S9.6   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.128u2            : Wilbert Pol updated NES PCM DMA to read data through the CPU address map. Aaron Giles fixed NES APU to work with high sample rates (don't know the bug #).
- 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            : Changed sound\nes.c/h and nesintf.c/h to nes_apu.c/h and nes_defs.h. 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
- 0.36b5             : Added cpu\m6502\tbln2a03.c.
- 0.31               : Added sndhrdw\nes.c/h and nesintf.c/h.
- 0.21               : Removed m6502\dasm.
- 0.20               : Added m6502\dasm.
- 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            : Added sound\k005289.c/h. 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.129u5            : Phil Bennett fixed K007232 garbled music.
- 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             : Added sndhrdw\k007232.c/h. 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            : Added sound\k051649.c/h. 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.129u1            : R. Belmont fixed 64-bit issue in the K053260 emulation.
- 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             : Added sound\k053260.c/h. 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.125u7            : Aaron Giles added save state support to K056800 host controller.
- 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             : Added sound\segapcm.c/h. 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             : Added sound\rf5c68.c/h. 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.125u7            : Aaron Giles added save state support to the RF5C400 sound core.
- 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   Sega/Yamaha 315-5560

- 0.125u7            : Changed name 'MultiPCM' to 'Sega/Yamaha 315-5560'. MultiPCM/315-5560 rewrite. All features are now supported including PLFO and ALFO [ElSemi].
- 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)


S14.3   ST0026

- 0.125u9            : H0pdmiYX0 fixed NiLe pitch calculation.
- 0.125u7            : ST-0026 NiLe (sound) emulation [Tomasz Slanina, R. Belmont]. Added audio to Super Real Mahjong P6.
- SOURCE: emu\sound\nile.c



S15.    Hudson Soft


S15.1   HuC6280

- 0.128u5            : Aaron Giles fixed all sets with HuC6280 as Audio Device (PCE-Based titles): Fatal Error after OK.
- 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
- 0.37b7             : Added sound\saa1099.c/h.
- 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            : Added sound\qsound.c/h. Removed sndhrdw\cpsq.c. 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.
- 0.35               : Added sndhrdw\cpsq.c.
- 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.130u3            : Simulate 'keyoff' in the SPU. The envelopes aren't actually emulated, but the sound is silenced after a key-off (by placing the sound in a 'release' state)  This prevents audiable sound from looping forever [David Haywood].
- 0.129u5            : Quick hack to delay installing the SPU DMA handler until the first write to the SPU as driver init is now called after the devices are created [smf].
- 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.125u7            : Atari Ace fixed a few build problems with the TMC0285 sound core.
- 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.125u7            : Aaron Giles added save state support to CAGE audio system.
- 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.130              : Aaron Giles fixed DCS2 speedup handler so it doesn't get lost during a memory remap. This should give a slight speed bump to the Seattle/Vegas games and to War Gods.
- 0.125u9            : Aaron Giles fixed some save state problems in the DCS driver. Still comes out garbled on a load, however. Extended memory.c to support up to 4096 banks.
- 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            : Stephane Humbert 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.
- 0.36b12            : Added sndhrdw\seibu.c/h.
- 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.130u3            : Aaron Giles removed msb/lsb handlers from taitosnd. Updated all drivers to call the 8-bit versions directly from the address maps.
- 0.37b8             : Added sndhrdw\taitosnd.c/h.
- SOURCE: audio\taitosnd.c
- GAMES: Taito - Rastan (1987), Rainbow Islands (1987), Superman (1988), Taito L-System, Taito F2 System and Taito B System


24.B   SNK Wave
- 0.127u2            : Added sound\snkwave.c/h. Nicola Salmoria fixed emulation of the "SNK Wave" custom sound used by Marvin's Maze and Vanguard II and made it into a proper sound core. 
- SOURCE: emu\sound\snkwave.c


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.127u2            : Lord Nightmare updated TMS5100 LPC tables based on mathematical analysis of 1st and 2nd derivatives of the values and comparison to the best quality patent image, which nearly always showed which values were in error. Some off-by-one issues may remain, but it is now nearly perfect. Further perfection will require PROMOUT dumping, which is planned.
- 0.125u1            : Lord Nightmare fixed the chirp table implementation in both the 51xx and 52xx chips.
- 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.127              : Oliver Stoenberg removed duplicated TMS5110 entry in sound.mak.
- 0.125u2            : Lord Nightmare added proper interpolation sub-cycles to the TMS5110 and TMS5220 ('PC' cycles and A/B subcycles of each) and updated comments.
- 0.125u1            : Lord Nightmare fixed the chirp table implementation in both the 51xx and 52xx chips.
- 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             : Added sound\tms5110.c/h, tms5110r.c, 5110intf.c/h. 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, Bagman (Valadon 1982) and Super Bagman (Valadon 1984)


S26.24  TMS5200
- 0.125u7            : Atari Ace fixed a few build problems with the TMS5200 sound core.
- 0.125u1            : Lord Nightmare updated TMS5200/5220 documentation and comments. Fixed the chirp table implementation in both the 51xx and 52xx chips.
- 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.
- GAMES: Zaccaria - Money Money (1983), Jack Rabbit (1984)


S26.25  TMS5220

- 0.129u2            : Phil Bennett and Jay Gallagher fixed TMS5220 speech in Turbo Sub.
- 0.125u5            : Additional documentation in the TMS5220 core [Lord Nightmare].
- 0.125u2            : Lord Nightmare added proper interpolation sub-cycles to the TMS5110 and TMS5220 ('PC' cycles and A/B subcycles of each) and updated comments.
- 0.125u1            : Lord Nightmare updated TMS5200/5220 documentation and comments. Fixed the chirp table implementation in both the 51xx and 52xx chips.
- 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               : Added sndhrdw\tms5220.c/h, tms5220r.c, 5220intf.c/h and tms5220.txt. 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.
- 0.28               : Added sndhrdw\votrax.c.
- 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.128u4            : Update S14001A core [Lord Nightmare]: Added chip pinout and operation notes.
- 0.125u9            : Update S14001A core [Lord Nightmare]: Improved filtering to be more accurate to the chip, changed internal audio renderer to produce 4 bit sound as the real chip does. Moved filter outside of the main rendering loop into the glue code. Note: With this update, you may hear a whining noise that was not previously present. This is accurate to the chip! The real chip would almost always have an analog filter placed on its output to suppress this whine.
- 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.129              : Aaron Giles added polling hooks for SP0250 DRQ line. The callback is now optional. If not provided, then the kick timer is not used. Converted gottlieb speech driver to use polling for SP0250 DRQ line.
- 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.129u4            : Nathan Woods added the ability to invoke CPU input lines with devcb callbacks. Changed SP0256 to use devcb callbacks. Updated Sauro driver to use this new feature.
- 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             : Changed sound\cvsd.c/h to sound\hc55516.c/h. 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             : Added sndhrdw\cvsd.c/h. 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.
- 0.30               : Added sndhrdw\vlm5030.c/h.
- 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), Yie Ar Kung-Fu (Konami 1985)
- PCB: SANYO VLM5030, DIP40
- SOURCE: sound\vlm5030.c



S26.9   SSI263
- PCB: SSI 263 Speech Synthesizer - Thayer's Quest (RDI 1984)
- SOURCE: drivers\thayers.c



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             : Added upd7759.c/h. 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)


S26.D   Digitalker
- 0.129u1: Added sound\digitalk.c/h. Olivier Galibert added digitalker speech emulation.
- NOTES: National Semiconductor's Digitalker. The history of this driver is a little strange. The real reverse-engineering work has been done by Kevin Horton (single-stepping the chip and everything) with assistance by Lord Nightmare who had done the work (with help from Mr. Horton) on the tsi s14001a, a predecessor of the digitalker.  Mr. Horton was not interested in publishing his findings, but provided full-rate resynthesized samples for the game scorpion. This driver is the result of analyzing these samples. 
- SOURCE: sound\digitalk.c
- PCB: MM54104 Digitalker speech (Scorpion)



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  RCA CDP1869

- 0.129u4            : Changed name 'CDP1869' to 'RCA CDP1869'. Cidelsa changes [Curt Coder]: Combined CDP1869 video and sound parts to one device.
- 0.129u1            : Curt Coder fixed sloppy rendering in CDP1869 that caused occasional crashes.
- 0.128u6            : CDP1869 devices now also require a CPU to be defined in the configuration, in order to know which CPU's registers to fetch. Updated all cdp1869 users to specify one [Aaron Giles].
- 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.129u1            : Added Beep sound to Tetris (bootleg of Mirrorsoft PC-XT Tetris version).
- 0.37b14            : Removed sound\beep.c.
- 0.37b7             : Added sound\beep.c/h.
- SOURCE: sound\beep.c


S27.72  Wave

- 0.37b14            : Removed sound\wave.c.
- 0.36RC1            : Added sound\wave.c/h.
- SOURCE: sound\wave.c


S27.73  SID

- 0.129u5            : Device-ized the SID code [Nathan Woods].
- 0.129              : Wilbert Pol cleaned up the SID interface.
- 0.128u7            : Wilbert Pol added running_machine parameter to the callback in the SID interface.
- 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)

S29.7   09R81P
- PCB:  The 09R81P IC is a kind of samples system controller, driving the OKI M5205 in Lucky 74. The IC is connected to Z80 through ports 0x00 to 0x05. Transmit the status (/busy) to port 0x00 (bit 0). Load the sample start offset from ports 0x00 & 0x01 and the ending offset from ports 0x03 & 0x04, then trigger the sample when the bit 0 of port 0x05 is activated.




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)
        TCA940       Thomson TCA940E AF Amplifier (Astrof, Ozmawars)
        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      TDA2003 sound 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 / MCS-51
  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   AT89C4051
  6.F   89C52
  6.G   89C55
  6.H   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.    Mitsubishi
  9.1   M50747
  9.2   M30624

 10.    Motorola
 10.1   M68701
 10.2   M68705
 10.21  M68705 MCU rom
 10.22  MC68HC705
 10.3   MC68HC11

 11.    Namco
 11.1   Cxx
 11.2   C68
 11.3   C69
 11.4   C70
 11.5   C71
 11.6   C74
 11.7   C75
 11.8   C76

 12.    National Semiconductor
 12.1   COP4xx
 12.2   COP410
 12.3   COP420
 12.4   COP421
 12.5   COP440

 13.    Nichibutsu
 13.1   1411M1
 13.2   1412M2
 13.3   1413M3
 13.4   1414M4
 13.5   NSC8105

 14.    Nintendo
 14.1   Nintendo VS System (VSNES)
 14.2   Playchoice security chip
 14.21  RP5H01
 14.22  RP5C01
 14.3   Aleck64 (Nintendo64 based hardware)

 15.    Sega
 15.1   Sega encryption

 16.    Seibu
 16.1   COPX-01
 16.2   COPX-02
 16.3   COPX-03

 17.    Texas Instruments
 17.1   TMS32010
 17.2   TMS32015
 17.3   TMS32020

 18.    Taito
 18.1   C-Chip

 19.    Other
 19.1   Program Protection
 19.2   Random Number Generator
 19.3   Opcode encryption
 19.4   DL57S22
 19.5   Toshiba T5324
 19.6   ASIC
 19.7   CAT702
 19.8   Address lines scrambling
 19.9   Dongle
 19.A   Custom security
 19.A1  Epoxy block
 19.A2  BBX

 20.    Programmable Logic Devices (PLDs)
 20.1   PAL
 20.2   GAL
 20.3   CPLD
 20.4   FPGA
 20.5   Other

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




P0.    The Decapping Project

- 30th July      2008: Guru - Thanks to Dox who sent a few more chips to be decapped. These chips are from Taiwan Chess Legend, Elvis, Kyros, Cow Race, D-Day, Double Dealer, Raiden II, Angel Eyes, Arkanoid, Croupier and Heavy Barrel.
- 11th June      2008: Guru - Speaking of decapping, I've just about got it all together, sort-of. I've just completed a BIG _preliminary_ update with everything that I've sorted out so far.... at least until I find more things to add to the list! There's so much stuff here that I keep finding things to decap(!?!). There's some minor work involved removing the chips and some serious work involved keeping track of everything and updating the decapping page (plus, remember I work full-time....) so there's still a few weeks/months before it will all go out. I'm also planning to add pics of every chip. In the meantime probably more stuff will arrive! There's at least a couple more wanted chips coming from Japan in the next big box that will arrive in 3-4 weeks and some other devs are going to send out some more chips soon. You might notice a lot of chips that are unknown and may or may not be important. I've decided to just grab everything that _could_ be useful for emulation purposes and send it out and see what happens. There's no guarantees that any of it will be successful, but we must try. Will collecting the decapping chips ever end?
- 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.
- WWW: http://www.mameworld.net/gurudumps/decap/index.html
- MESS Dumping Project: http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=27098#Post27098



P1.    Alpha Electronics

P1.1   ALPHA-8201
- 0.128u6            : Pointer-ified the ALPHA-8201 CPU core [Aaron Giles].
- 0.125u7            : Atari Ace fixed a few build problems with the ALPHA8201 CPU core.
- 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

- 0.126u5            : Nicola Salmoria updated Alpha 8302 MCU simulation to match newly dumped internal ROM. Added the ROM to Champion Baseball 2.
- 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

- 0.127u1            : Nicola Salmoria added 8303 ROM to Bull Fighter, Equites, Exciting Soccer II and Splendor Blast and updated MCU simulation to match the new findings.
- 28th August    2008: Corrado Tomaselli dumped the MCU8303 rom.
- 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.
- 0.31               : Added machine\slapstic.c.
- 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

- 0.128u3            : Removed cpu\ds5002fp\ds5002fp.c, ds5002fpdasm.c, ds5002fpops.c and ds5002fp.h. Merged DS5002FP into MCS51 [Couriersud]: Merged DS5002FP. Disassembler now uses type specific memory names. Merged DS5002FP disasm. Added 83C751 memory names to disassembler. Delete DS5002FP specific files. Removed unnecessary cpu callback in wrally. DATA_MAP ==> IO_MAP in wrally.
- 0.125u2            : R. Belmont fixed World Rally MCU comms on big-endian.
- 0.125u1            : Added cpu\ds5002fp\ds5002fp.c, ds5002fpdasm.c and ds5002fpops.c. Added DS5002FP CPU core [Manuel Abadia].
- 12th May       2008: Manuel Abadia - World Rally emulation is complete. I implemented priorities (that were trickier than I thought), shadows/highlights and a few missing bits in the video hardware. The game is fully playable from beginning to end without any problem as far as I can tell. I thought there was a bug in the video hardware emulation somewhere... So I plugged my PCB and compared it to the driver. The problem is also in the original arcade game. Because of the way an arcade monitor works, the problem is nearly unnoticeable in the original game. I also checked if the original PCB had the same "shadow effect" for the tiles, yes the hardware works that way. Something curious about the protection... Javier told ElSemi that the protection of this game took 8 months of work, so imagine how complicated it was... even the dallas has some code that performs some pseudorandom dummy accesses to the shared RAM to make black box attacks even more difficult. To clarify a question about the other protected games, having the World Rally dallas code does not help to emulate the protection of them.  As MAME now has a DS5002FP core and the other games are almost fully emulated, if we get the dallas code for a game, it will be playable quickly. Finally, I want to thank to all the people that made this possible. It was cool to be part of this. It has brought me some good memories and healed my wounds with Gaelco.
- 10th May       2008: Manuel Abadia - Playable status reached: Javier sent us (via ElSemi) detailed information about how the encryption process worked. However, he told us that the sheets of paper that contained the encryption info were a bit difficult to read in some places (remember that this protection was designed 15 years ago) so probably there was some mistakes in the excel file he sent us. ElSemi and I tried to add it with the information he gave us but we didn't have success. Nicola Salmoria did an excellent work (as always) consolidating the information and obtaining the missing information. He generated a working decryption function that not only works for World Rally, but also for Squash and Thunder Hoop. Mike Coates also completed the interface to get the data from a World Rally PCB, so he was able to supply the encrypted/decrypted data that was needed to get the specific details to decrypt World Rally properly. Special mention to Andreas Naive too. The high level information Javier told us a few days ago was already discovered by Andreas and posted in his page a couple of months ago. Before Javier sent us detailed information about how the encryption worked I contacted Andreas Naive about the encryption and he told me that he didn't have free time at the moment to look at it. However he told me an intuition he had about the algorithm: "I remember that my last feeling was that to decipher each 16 bits block, it was done in 3 chunks: a first 6 bits chunk and then two 5 bits chunks, each of them based in a/some bits of the first chunk. I don't remember exactly which ones, but the first chunk was the one with a simple structure (based on the tables I published), while the other two were the ones that shown a more complex structure (and carry effects)". He was completely right as that was how it worked the encryption that Javier sent us. It is good to have geniouses around. After adding the decryption to the driver the game looks fine. It has a few graphic glitches that will be fixed soon but it seems to be PLAYABLE.
-  7th May       2008: Manuel Abadia - The Dallas DS5002FP core is complete. The additions to the 8051 core are: Extra Special Function Registers, Byte-wide Bus Support, Memory Partition and Memory Range, Bootstrap Configuration, Power Fail Interrupt, Timed Access, Stop Mode and Idle Mode. I didn't bother to add support for Peripherals, the Reprogrammable Peripheral Controller or CRC-16 support because it isn't used by the game. The communication between the Dallas and the main CPU seems to be working, however, the game writes some bytes to the encrypted Video RAM, it reads them back and then makes some calls based on the decrypted data. As the current decryption is wrong, the game doesn't work yet and never uses the dallas for anything interesting right now. The decryption of the Video RAM is in the same state as it was. However, ElSemi asked Javier for information about the decryption and he is trying to help us. He didn't remember how it was performed but we send him the information we got about it in 2002 (when Mike connected the PCB to the fluke) to refresh a bit his memory. Thanks to that, he gave us another point of view about how the encryption may work. Even if he is right, we still need to get data from the original PCB. Hopefully, somewhere in the process we end up with a clean decrypt function that uses no tables. Understanding some code I was able to guess some decrypted values and get this (see snapshot). It looks really ugly as the colors for the tiles aren't decrypted properly but this finally confirms that World Rally uses the same Video Hardware as Target Hits. The only change seems to be the additional palette entries for the night races. I have seen how the palette was configured in a night race and I have an idea of how the palette works for the night races (not very different from World Rally 2), but we'll have to wait until the game works to implement it. So, the current status is that if the Video RAM is decrypted properly and we are lucky, the game should work without the light effects (and maybe some priority problems) and be playable. If we are not that lucky, hopefully the problems are not difficult to find and fix.
-  5th May       2008: Manuel Abadia - If you have tried to execute World Rally since it was added to MAME you have seen the precarious state of the driver. The protection of World Rally is double: 1. Encrypted Video RAM: The encrypted Video RAM transforms a 32 bits value written to it to another value that is really complex to derive from the original value. This protection was also used in Thunder Hoop and Squash. Mike Coates connected a fluke to his PCBs and got a 4 GB file will all possible combinations (2^32) for Thunder Hoop and Squash.  Using that file, the encryption process was replicated.  However, it was not very practical to require a 16 GB file to run the game. Nicola Salmoria studied the file and generated some code (about 400 lines) that replicated the original encryption. That's why you can play Thunder Hoop and Squash. Why World Rally encryption is incomplete? All of us wanted to see World Rally running before any other game, so we started studying World Rally before Squash and Thunder Hoop. In that time, we thought that the encryption was only performed in 16 bits, not 32. Unfortunately, when Mike got all decrypted values (2^16), the code was clearly showing that the decrypted values were not correct in most cases (for example, one of the methods that draws the tiles uses a decrypted value for the number of tiles to draw. That's why the power on self test results and other screens look horrible right now).  After we find that out, the decryption efforts were centered in the other games. As World Rally was not going to be playable unless the dallas code was dumped (something that seemed unlikely), it has remained that way. 2. Dallas DS5002FP secure MCU: The Dallas MCU in the Gaelco games has some critical code that handles inputs, objects manipulation and other complex calculations that prevent the game from working properly (Take a look at World Rally 2 if you don't know what I mean). The DS5002FP MCU has been one of the best chips for protecting information on its era making emulation of these games impossible for now. There are some specialized labs that claim to be able to get the code from a DS5002FP but it is an incredibly expensive process we can't afford. I have to admit that I thought that I'd never see World Rally emulated, as I approached some people at Gaelco and Zigurat for the Dallas code without luck. However, the other day I received an email that changed my mind. Miguel Angel Horna (ElSemi) did a talk at Lleida Lan Party about emulation. At the party he met one of the Gaelco founders (Javier Valero) that was there to speak about the arcade game industry. ElSemi and Javier talked about the protection in some Gaelco games and Javier was kind enough to provide the dallas code for World Rally. With the internal code of the DS5002FP it is just a matter of time to finally have a working driver in MAME. I have been completely inactive from MAME development for a while but as I worked on the drivers of all the Gaelco 2D games (except Master Boy) and I spent a lot of time and money on them, I thought it was a good time to resume my work on MAME. Mike Coates is trying to get all the possible values from World Rally Video RAM so we can advance in that area too. Currently I am writing a DS5002FP core to run the dallas code. The DS5002FP is just a 8051 MCU with some additions and as MAME already has a 8051 core things are going fast. For example, the initial coprocessor test works (although it is a trivial test to pass without the dallas code). Also, adding the Power Fail Interrupt of the dallas I managed to see this screen that is supposed to be seen when the dallas is dying. After the both protections are emulated the driver will need more work as probably the video hardware emulation isn't complete and needs some tweaks here and there but I'm confident that World Rally will be playable in a not so distant future. I don't know if Javier will give us more dallas code or not, but hats off to him for this one. Also, thanks a lot to ElSemi for being able to get the dallas code from him.
-  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)
- Web: http://www.scribd.com/doc/931673/Dallas-DS5002FP-protection-cracking
- PCB: DS5002 (Aligator, Touchgo, Wrally2), DS5002FP (Thoop, Thoop2, Wrally)


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.
- NOTES: Banbam has a Fujitsu MB8841 4-Bit MCU for protection labeled SUN 8212.
- SOURCE: cpu\mb88xx\mb88xx.c
- GAMES: Route 16 (Tehkan/Sun 1981), Kangaroo (Sun Electronics 1982), Arabian (Sun Electronics 1983), BanBam (Sun Electronics 1984), 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: Phil 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 / MCS-51

- 0.128u6            : Aaron Giles removed hack for setting MCS51 serial callbacks. Updated micro3d to use new functions.
- 0.128u4            : Switched MCS51 to new memory functions [Couriersud].
- 0.128u3            : Couriersud converted the MCS-51 core to reference data via pointers. Merged DS5002FP into MCS51 [Couriersud]: Merged DS5002FP. Disassembler now uses type specific memory names. Merged DS5002FP disasm. Added 83C751 memory names to disassembler. Delete DS5002FP specific files. Removed unnecessary cpu callback in wrally. DATA_MAP ==> IO_MAP in wrally.
- 0.128u2            : Renamed cpu\i8051\i8051.c/h, 8051dasm.c and i8051ops.c to cpu\mcs51\mcs51.c/h, mcs51dasm.c and mcs51ops.c. MCS-51 improvements [Couriersud, Jim Stolis]: Fixed split timer mode. No interrupts for timer 0 modes 0,1,2 while timer 1 in mode 3. MCS51 core now supports 4 interrupt levels depending on CPU type. According to Philips, 80C31 is a 80C52 family member with 128K internal ram and no rom. Implemented CMOS features: Powerdown & idle. Added comments about special function registers on Philips 80C52. Cleaned up reset routines. Fixed INT0 & INT1 interrupt line handling. Finally move cpu/i8051 to cpu/mcs51, rename files and some constants. Quotes from the documentation added to the source as well. Started DS5002FP integration.
- 0.128u1            : MCS51/I8051 improvements [Couriersud, Jim Stolis]: Improved serial port timing. Better infrastructure for adding more variants like DS5002. Fixed port reading. Rewrote Macros for better readibility. Fixed and rewrote Interrupt handling. Now returns INTERNAL_DIVIDER and adjusted cycle counts. Remove unnecessary and duplicated code. Remove unnecessary functions. Rewrite to have sfr-registers stored in int_ram. Debugger may now watch sfr-registers as well. Implemented interrupt callbacks (HOLD_LINE now supported). Runtime switch for processor type - remove ifdefs. Internal memory maps for internal rom versions (internal ram now displayed in debugger). More timer cleanups from manual. Fixed timer 2 interrupts. Implement serial mode 2/3 rx and tx clock handling. Remaining games checked and adapted to changes in cpu core. Cardline still broken. I need the exact and complete cpu name. Added more variants 803X, 80CXX and AT89C4051. Fixed segas18.c (segaic16.c) mcu maps. Fixed sslam.c. Fixed issue with core allocation of ram (duplicate savestate) in limenko.c and videopkr.c.
- 0.127u7            : Grull Osgo fixed i8051 timers and the AJMP opcode to take 2 bytes instead of 3.
- 0.126u3            : I8051 CPU core timer updates [Wilbert Pol]: Added support for timer mode 0 (13 bit timer). Cleaned up timer code a bit, fixing some off-by-one errors when timers overflow.
- 0.125u5            : Jim Stolis fixed the timer 0's second split counter in the i8051 core, that was incorrectly checking the Timer 1 Run Control Bit.
- 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            : Stephane Humbert 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: Phil 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: Phil 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\mcs51\mcs51.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.129u6            : Aaron Giles added port names to the taito8741 device pending its proper devicification.
- 0.104u9            : Tatsuyuki Sato fixed Joshi Volleyball and Great Swordsman, which was broken in an earlier update.
- 0.35RC1            : Added machine\tait8741.c/h.
- 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   AT89C4051
- 0.128u1            : MCS51/I8051 improvements [Couriersud, Jim Stolis]: Added more variants 803X, 80CXX and AT89C4051. Replaced I8051 CPU2 with AT89C4051 in Spotty (Ver. 2.0.2).
- SOURCE: cpu\i8051\i8051.c
- PCB: AT89c4051-24PC (Beastrzb, Spotty)


P6.F   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.G   89C55
- PCB: Atmel 89C55  8-Bit Microcontroller with 20K Bytes Flash, KD89C55A (SuperMoto)


P6.H   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.128u6            : Pointer-ified the PIC16C5x core [Quench].
- 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.    Mitsubishi

P9.1   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)

P9.2   M30624
- NOTES: The M30624FGAFP is a Mitsubishi (Renesas) M16/62A 16bit microcomputer. It has 256 KB of internal flash ROM + 20 KB of RAM.
- SOURCE: drivers\itgambl3.c
- PCB: M30624FGAFP-251G108 (Ejollyx5, Grandprx)



P10.    Motorola

P10.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)


P10.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)


P10.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)


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


P10.3   MC68HC11
- 0.128u6            : Pointer-ified the MC68HC11 CPU core [Aaron Giles].
- 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)



P11.    Namco

P11.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.

P11.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

P11.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

P11.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)

P11.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)

P11.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

P11.7   C75
- 0.127u1            : Namco NB 1/2 work [Olivier Galibert]: Shares the memory with the C75. Renames the C75 region to C7x from user4. Implements the C75 reset/halt control. Implements the irqs more correctly.
- 26th August    2008: Guru - A couple of items arrived(Espgaluda 1 and 2)... Now for some REALLY BIG NEWS.....I've also been working on Namco's M37702 Sound MCU (C75) with Olivier Galibert.
- 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

P11.8   C76
-  2nd September 2008: Guru - Namco System 11 BIOS (C76) dumped: Special thanks again to Olivier Galibert for his superior trojan writing skills.
- SOURCE: audio\namcoc7x.c
- PCB: NamcoSystem11




P12.    National Semiconductor

P12.1   COP4xx

- 0.129u1            : Added cpu\cop400\cop400.c and 400ops.c. COP400 CPU core refactoring [Curt Coder]: Added state table for the debugger. Grouped all cpu types under a single makefile entry. Removed duplicate code.
- 0.128u4            : Pointerized the COP400 CPU cores and refactored the COP400 CPU cores to use the new memory functions [Curt Coder].


        Types   (NOTES: The National Semiconductor COP4xx MCUs manages CPU communnication)

        COP400
        COP401 is a ROMless version of the COP410
        COP402 is a ROMless version of the COP420
        COP404 is a ROMless version of the COP444, which can emulate a COP410 or a COP424
        COP410
        COP411 is a 20-pin package version of the COP410, missing D2/D3/G3/CKO
        COP420
        COP421 is a 24-pin package version of the COP420, lacking the IN ports
        COP422 is a 20-pin package version of the COP420, lacking the IN ports
        COP424 is functionally equivalent to COP444, with only 1K ROM and 64x4 bytes RAM
        COP425 is a 24-pin package version of the COP424, lacking the IN ports
        COP426 is a 20-pin package version of the COP424, with only L0-L7, G2-G3, D2-D3 ports
        COP440
        COP444
        COP445 is a 24-pin package version of the COP444, lacking the IN ports



P12.2   COP410

- 0.129u1            : Removed cpu\cop400\cop410.c and 410ops.c.
- 0.127u2            : Enabled internal COP410 program map [Curt Coder].
- 0.125u5            : COP4xx [Curt Coder]: Fixed LEI instruction (cpu\cop400\410ops.c). 
- 0.125u4            : COP4xx updates [Curt Coder]: Added HALT opcode and halt mode to the 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].
- SOURCE: cpu\cop400\cop410.c


P12.3   COP420

- 0.129u1            : Removed cpu\cop400\cop420.c and 420ops.c.
- 0.125u5            : COP4xx [Curt Coder]: Fixed LEI instruction (cpu\cop400\410ops.c). 
- 0.125u4            : COP4xx updates [Curt Coder]: Added Microbus support, clock divisor selection and CKO mode selection to the COP420. Changed Thayer's Quest keyboard interface to at least slightly resemble the schematics.
- 0.125u3            : Curt Coder fixed COP420 instructions JSRP, LBI, LQID, SKT, XAS and INIL. Draco now has sound. Fixed cycle count for extended opcodes. Added CKO general purpose input.
- 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. General cleanup.
- 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.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.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.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.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.
- SOURCE: cpu\cop400\cop420.c
- GAMES: Draco (Cidelsa 1981), Looping and Sky Bumper (Venture Line 1982), Thayer's Quest (1984)


P12.4   COP421

- 0.125u5            : COP4xx [Curt Coder]: Added COP421 variant. Fixed LEI instruction. 
- SOURCE: cpu\cop400\cop420.c
- GAMES: Thayer's Quest (RDI Video Systems 1984)



P12.5   COP440

- 0.129u1            : Removed cpu\cop400\cop440.c and 440ops.c.
- 0.128u4            : Added cpu\cop400\cop440.c, cop440ds.c and 440ops.c. 
- SOURCE: cpu\cop400\cop440.c





P13.    Nichibutsu

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

P13.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)

P13.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

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


P13.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)




P14.    Nintendo

P14.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


P14.2   Playchoice security chip

P14.21  RP5H01

- 0.37b6: Added machine\rp5h01.c/h.
- 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)



P14.22  RP5C01

- 0.129u4: Nicola Salmoria and Bob Seidel added basic support of RP5C01 to remove (most) protection kludges in Super Punch-Out.
- SOURCE: drivers\punchout.c




P14.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



P15.    Sega

P15.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             : Added machine\segacrpt.c. 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



P16.    Seibu

P16.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.
- SOURCE: mame\machine\seicop.c
- GAMES: Legionnaire (TAD 1992), Seibu Cup Soccer (Seibu 1992)
- PCB: COPX-D1 (cupsoc), COPX-01 (legionna)


P16.2   COPX-02
- 0.124u3            : Seibu implementation cleanups [David Haywood]: Added COP/Heated Barrel ram clear stuff. Tried to make COP a bit more generic, breaks a few things for now, but better than duplicated code all over the place.
- 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.
- SOURCE: mame\machine\seicop.c
- GAMES: Heated Barrel (Tad 1992), Denjin Makai (Seibu 1993), Zero Team (Seibu 1993)
- PCB: COPX-D2 (Rise Corp. 1992), DIP40 (denjinmk, heatbrl, zeroteam)


P16.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.
- SOURCE: mame\machine\seicop.c
- PCB: COPX_D3.357 (Raiden DX Seibu 1996)


P17.    Texas Instruments

P17.1   TMS32010
- 0.128u6            : Pointer-ified the TMS32010 core [Quench].
- 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             : Added cpu\tms32010\tms32010.c/h, 32010dsm.c and dis32010.c. 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)

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

P17.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




P18.    Taito

P18.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.
- 0.34b8             : Added machine\cchip.c.
- 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)




P19.    Other

P19.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.


P19.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 ?)


P19.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.

P19.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


P19.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)


P19.6   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)


P19.7   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)


P19.8   Address lines scrambling
- SOURCE: drivers\afega.c


P19.9   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


P19.A   Custom security

P19.A1  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)

P19.A2  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





P20.    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.



P20.1   PAL
        PAL = Programmable Array Logic

        - 16th February  2009: Charles MacDonald - If you do not want to build the PAL reader, there is a very low-cost alternative for dumping combinatorial (not registered) PALs. You can construct an adapter that connects a 20-pin PAL to a 32-pin socket. By reading the PAL in a device programmer as a 27C020 EPROM you will get a 256K dump which the PAL analysis software can interpret. Please note that while this has worked in some cases, because it relies on the operation of your device programmer the results cannot be guaranteed to be accurate. One person told me about several good dumps that were made with the adapter and just a few PALs gave weird results. When all the PALs were later redumped on the dedicated PAL reading hardware the correct dumps were still correct and the bad dumps were now read properly. Keep in mind that it is just a hack.
        - 15th January   2009: Charles MacDonald - The third revision of the PAL reader has had an update to fix a problem where USB enumeration wouldn't always work. Check out the online instructions for a step-by-step guide of how to modify the PCB and new PIC firmware. Current projects under development include: * Communications board for the PC-Engine using the new DLP-245R USB module. * USB-based RCA Studio 2 cartridge reader. * PAL programmer that interfaces directly with the PAL dumper. The latter should help testing different configurations as the chip can be programmed then dumped in one step and without removing and inserting chips over and over.
        - 21st August    2008: Charles MacDonald - This week I finished assembling and testing the third version of the PAL reader hardware. Both 20-pin (16L8) and 24-pin (22L10) devices can be dumped, though the analysis software needs some considerable changes to support 24-pin chips. I'm moving towards a more device-independent way of analysis that could support other programmable logic devices of varying input and output pin counts, though I don't have plans at the present to make a PAL reader capable of doing that. The power switch (ST890C) works very nicely, it has an output that is asserted when there is a short circuit or an overheating condition and will cycle its power output when it cools down sufficiently to continue. This caught a short circuit on the PCB as I noticed the "fault" LED was always lit. I tested a few registered PALs and the power-up reset works as expected, the only quirk was that the clock input needs to be low for the reset to happen. If it's held high, not all of the macrocells are reset to '1'. This will allow all possible transitions from the reset state to the next state to be mapped, which the previous versions of the PAL reader couldn't do without manually cycling the power. Not something you'd want to do 256 times. What didn't work was the DS1233 reset generator, which should keep the /RESET output low for short while after the ST890C power output has reached a valid level. Instead, it directly follows the power output state, low when off and high when on. Without that necessary delay I can't accurately determine when the 'settling' time for the PAL has elapsed, at which point its power-on reset sequence is complete. A workaround was to insert a short delay on the PC side, but I would much rather find a better solution. There is an expansion connector intended for a PIC12F675 with all the power and related control signals available, so it should be possible to find a more suitable part or circuit and connect it there, or just use a PIC to monitor the output. And if the software was informed about the kind of PAL being dumped, it could poll the PAL outputs until they were reset though that would increase the time it took to process a registered PAL. Overall I am quite pleased with the results. The design is becoming more refined and the capabilities are increasing. Once it's ready for a release I will update the PAL reader package with the new files, PCB layout, and software.
        -  6th August    2008: Charles MacDonald - I had received reports of PALs that couldn't be replaced because they used more input terms than a PAL supports. While the results were functionally correct and would compile for a virtual device, the results wouldn't fit in a replacement GAL16V8. A shortcoming in the analysis process was revealed where feedback wasn't properly taken into consideration. PALs have feedback taken from the point between the output buffer and bonding pad, which can be used as an input term by other outputs. Because the feedback is tapped at this particular point, it can be driven by the PALs output, or when the pin is tristated it can be driven by an external circuit. This allows for bidirectionality instead of forcing a pin to be input or output only. I had assumed WinCUPL would be able to minimize equations by taking the feedback of other outputs into account. But it doesn't, and for good reason: this is an unsafe optimization. If the pin in question was ever tristated then the feedback wouldn't represent the result of the logic associated of it, instead it would assume whatever state external circuitry on the pin set it to. Another less likely situation is that the output buffer of the PAL could be overridden if it was strongly driven high or low, say during a bus conflict, which would again make the feedback incorrect. From a design standpoint this isn't really an issue as the designer would always know if they wanted to use feedback or not. In retrospect it's probably pointless for the design software to try to work feedback into the optimization process because it would be explicitly specified. In terms of reverse engineering, this adds extra complexity to the analysis involved. I have started updating the software to take this into account, and it will likely take a while to work out all the associated issues. On the flip side it's nice to know that out of the many PALs people have dumped this was the only significant issue and that the results weren't really even incorrect, just not optimal. Special thanks to Nicola Salmoria for making sense out of the equations, and Chris Hardy and Corrado Tomaselli for providing PAL dumps, tracing PCB connections, and sharing information.
        - 27th July      2008: Charles MacDonald - I have been working with Chris Hardy to determine how the Bagman security chip works. It is a PAL16R6 clocked independently of the CPU at about 30 Hz. A new 6-bit random number is generated each time and can be read by the Z80 as needed. It generate 55 unique values before the sequence repeats. There are many different ways the internal storage (state data) of a PAL can be linked together to form elements like shift registers, latches, and counters. Rather than try to determine these very specific configurations, it's easier to look at the PAL from a generic point of view. The Bagman PAL has 6 registered macrocells and 8 inputs, so that's 64 possible states and 256 possible input configurations per state. This can be represented by a 'transition table', which says which state will be selected when the device is clocked, based on the current state and input settings. A problem arises as you fill out the table by feeding data to the PAL and recording the results: eventually you may reach a point where a very specific sequence of states has to be stepped through in order to reach the 'target' state you are mapping the inputs for. The rate at which the table is filled drops dramatically when this happens. To get around this I added code that checked if the current state was completely mapped out, and if so, it would find the path of state transitions that was necessary to reach the target state that needed further mapping. If no such path exists from the current state, a different state is selected and the path check is made again. This allowed all the input lists to get completely filled out for every state that was available. When analyzing the inputs, it was surprising to see that none of them were used by the registered logic. The address bus is available to the PAL, but does not affect random number generator. The bit from the timing circuit also wasn't used, and functioned independantly as an inverter. This greatly simplifies how the PAL functions as none of the inputs need to be taken into consideration when examining state changes. It's also highly unusual in terms of your typical registered PAL implementation. The next step was to create a replacement. Some of the initial designs we tested for a 16V8 didn't work, so I moved to a 22V10 (the only GAL I can program), dumping it through the PAL reader using a 22V10 to 16V8 adapter I made for the earlier CPS-2 project. As it turns out there is a strange quirk in WinCUPL; the state machine description which I generated from the transition table would compile, but only the optimized results (represented as logic equations) would generate a valid JED file for the 16V8. This was easy to fix, just cut and paste the results from the simulator output back into the CUPL source. But it is unfortunate this happens at all. Eventually we had a working GAL16V8 replacement for the Bagman PAL that produced identical output as the original part. Problem solved!
        -  9th July      2008: Charles MacDonald - I've been working on the PCB layout for the third revision of the PAL reader. This new version will support 24-pin devices like the 20L8 and 20L10. It has a software controlled power switch so that registered devices can be initialized to a known state in a consistent manner by causing a power-on reset. If this works as expected, it should allow registered devices such as the PAL16R8 to be dumped. If it doesn't, the extra circutry can be bypassed with a jumper and it will function normally. I have also tried to address usability issues; there are mounting holes for standoffs, all parts except a SOIC-8 chip are socketed for easy repair, and there is more clearance around the PAL socket. There is still a lot to do as the new design has to be tested to confirm its operation, and the dumping and analysis software will need some considerable rework for the larger devices. But this is another step towards a better solution for dumping PALs.
        - 11th May       2008: Guru - I received a small custom adapter from Charles MacDonald. It's used to raw-read PALs, especially protected ones. Very nice little gizmo that will hopefully be useful for solving some memory map related issues in MAME. I've already used it to dump the PALs from Captain Commando (CPS1).
        - 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



P20.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)



P20.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)




P20.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)


P20.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  6520
  6.12  6821
  6.2   PPI (Progammable 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
  7.5   CDP1852

  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
 12.61  Pioneer PR-8210
 12.62  Pioneer LD-V1000
 12.63  Philips 22VP931

 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.126u2            : Aaron Giles changed the 6532 RIOT device into a proper device. Rewrote the logic to be simpler and leverage the new attotime functions. Changed the I/O port setters to specify a mask, and changed the I/O port callbacks to pass in the previous value. Updated tourtabl and gameplan drivers to use the new device interface.
- 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.128u7            : Some PIC8259 updates [Wilbert Pol]: Fixed operation of edge-triggered interrupts. INT output line is now cleared when an IRQ is acknowledged. Implemented basic OCW3 features.
- 0.128u6            : Wilbert Pol added MDRV_PIC8259_ADD macro.
- 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.128u6            : Atari Ace modified the pc16552.h interface to eliminate some more global Machine variables. More deprecat.h includes eliminated.
- 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.127              : Robiza began implementing 68681 device in Skat TV.
- 0.125u5            : Updated 68681 DUART [Mariusz Wojcieszek]: Converted to device interface. Converted to 8 bit device. Added input and output port. Added X1/16 timer.
- 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.126u4            : 8257DMA device now require device callback handlers instead of machine handlers. Updated affected drivers accordingly [Couriersud].
- 0.126u2            : Miodrag Milanovic fixed 8257 DMA terminal count stop for autoload mode and added callback function existance check.
- 0.125u7            : Implemented 8257 DMA controller as proper device [Couriersud]: Rewrote 8257dma.[ch]. Updated dkong.c accordingly.
- 0.125u3            : Implemented autoload mode in 8257 DMA [Miodrag Milanovic]: Added support for autoload mode. Fixed bug in calculating count.
- 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.128u6            : Wilbert Pol added MDRV_DMA8237_ADD macros.
- 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  6520
- PCB: SY6520/SY6820, 40 Pin, Peripheral Interface Adapter Plug (Comg239), 6820 (Copsnrob)


I6.12  6821

- 0.129u6            : Removed machine\6821new.c/h. Aaron Giles converted all drivers to the new device-based 6821 PIA.
- 0.129u3            : Nathan Woods converted 6821new device to use the module DEVCB. Updated Williams drivers to remove trampoline functions.
- 0.129u1            : Added machine\6821new.c/h. Nathan Woods introduced a parallel 6821 PIA implementation, as a MAME device (6821new.c). Ported the Williams drivers over to use this new PIA implementation.
- 0.128              : Phill Harvey-Smith added function to get the status of CA2 on the 6821 PIA emulator.
- 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.
- 0.30               : Added machine\6821pia.c/h.
- 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 (Programmable Peripheral Interface)

I6.21  8255

- 0.129u3            : Aaron Giles converted the 8255PPI device to use the structure of new module DEVCB, and updated all users to use the DEVCB macros, removing some unnecessary trampoline functions along the way.
- 0.127u6            : 8255 PPI interface cleanup [Aaron Giles]: Added MDRV_PPI8255_ADD, MDRV_PPI8255_RECONFIG and MDRV_PPI8255_REMOVE macros; updated all drivers to use them. Changed callbacks to device read/write handlers intead of machine read/write handlers; updated all drivers accordingly. Normalized function and variable names to be lower_under. Removed a number of redundant interfaces from the galaxian/scramble line of games.
- 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 programmable peripheral interface. It has three 8-bit I/O ports. 24 I/O ports are divided into two groups (Port A and B) which are programmable independently by control words provided by MPU. The PPI has three operation modes (Mode 0, 1 and 2) and is capable of versatile interface between MPU and peripheral devices. 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.129u4            : Nathan Woods made the 6522 VIA implementation use devcb.
- 0.128u6            : Nathan Woods changed the 6522 VIA implementation to be a device.
- 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.129u5            : Dirk Best added support for the /PC output pin to the CIA emulation.
- 0.129u4            : Nathan Woods changed 6526cia to use devcb.
- 0.129u1            : Nathan Woods added a validity check to the 6526 CIA emulation.
- 0.128u5            : Made the 6526/8520 CIA implementations be devices [Nathan Woods]: Added differentiation between the r1 and r2 versions of the 6526; not acting on it yet.
- 0.125u1            : Robiza added feature to the cia6526: In READ operation the value can be forced by a external circuit; this feature is necessary for MESS.
- 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.128u5            : Made the 6526/8520 CIA implementations be devices [Nathan Woods].
- 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.129u4            : Curt Coder refactored the ACIA6850 to use devcb. Phil Bennett adjust the 6850acia rx/tx bit timers on a control write if the divide ratios have changed.
- 0.128u5            : Made the 6850 ACIA a device [Nathan Woods].
- 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
- 0.129: Added machine\i8243.c/h. Aaron Giles added i8243 implementation. Connected 8243 properly to monsterb and system 16a sound. Unified interface to 8243 expander chip. Converted tnzs and decocass to the new interfaces.
- NOTES: Intel 8243 Port Expander
- SOURCE: machine\i8243.c/h
- 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), AM8279PC programmable keyboard / display interface (Unknown PCB)

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.130u3: Added machine\i2cmemdev.c/h. Samuele Zannoli added device-based implementations of the EEPROM and i2c devices.
- 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)

I7.5   CDP1852
- 0.129u4            : Cidelsa changes [Curt Coder]: Refactored CDP1852 to use devcb.
- 0.125u1            : Added machine\cdp1852.c/h. Curt Coder added CDP1852 I/O buffer chip, and used it in Altair/Draco.
- SOURCE: machine\cdp1852.c



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.126u5            : Moved mame\machine\pckeybrd.h to emu\machine\pckeybrd.h.
- 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\pckeybrd.h
- 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.130u3            : Build the IDE features table only when there is a CHD available [Curt Coder].
- 0.126u4            : Aaron Giles changed the IDE interfaces to default to choosing the region with the same tag as the device for its master disk (assuming no slave). Added support for specifying explicit master/slave disk regions as part of the configuration, though slave disks are still not supported yet.
- 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.126u4            : Disks opened by the romload module are no longer identified by index. Instead, they are identified by the region they were loaded in. This generally means one disk per region. get_disk_handle() now takes a region name in place of an index. Updated all callers to do this. The SCSI modules in particular posed a challenge to make this work, so watch out for potential bugs there [Aaron Giles].
- 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 Stoenberg 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\scsicd.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.129u5            : Couriersud added register SXFER (0x05) to the 53c810 - nothing more. This reg determines SCSI transfer speeds. scud / scuda now fatalerror with writes to reg # 0x70.
- 0.125u5            : Aaron Giles changed the 53C810 SCSI controller read/write handles to proper READ8/WRITE8_HANDLER callbacks so they can eventually be used directly.
- 0.125u4            : R. Belmont updated the 53c810 SCSI adapter to pass IRQ state with the IRQ callback.
- 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.128u6           : Aaron Giles made the PCI bus a device. The bus is declared in the machine config, and the devices attached to it are enumerated there. Eventually, the PCI config read/write functions should be moved to well-known functions within the device, but for now they are kept separate.
- 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.125u7           : SMC91C9x [Aaron Giles]: Converted to proper device. Updated seattle and vegas drivers to allocate devices. Added separate 91C96 device for eventual 'San Francisco Rush 2049' use. Cleaned up code. Added save state support to the smc91c9x emulator.
- 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.131              : The CHD format has undergone a change with this release. The main reason for this change is to include some of the key metadata into the hashes for the CHDs. This ensures that the metadata is valid and prevents abuse. The first impact you will find is that all of your CHD differencing files are invalid. Just delete your "diff" directory contents entirely. The second impact is that all your existing CHDs will warn you that they have incorrect hashes. This is expected. Your old CHDs should still work fine, so if you can live with the "bad ROM" warnings, you don't really need to do anything. However, if this bugs you or you want to be "clean", you can update your CHDs, using this command line:  chdman -update <chdfile> <newchdfile> for each one of your CHDs. This will take a while, but will produce CHDs that match the new checksums posted in the drivers.
- 0.130u3            : Build the IDE features table only when there is a CHD available [Curt Coder].
- 0.130u1            : Aaron Giles updated CHD format to version 4. Checksums are now computed and stored separately for raw data and metadata, and metadata is now checksummed by default. Aaron Giles updated chdman to support a generic metadata addition system: chdman -addmetatext <chdfile> <tag> [<index>] <sourcefile> and chdman -addmetabin <chdfile> <tag> [<index>] <sourcefile>. Aaron Giles changed the CHD verify interfaces to pass back a structure containing all the necessary data for verification and fixing. Aaron Giles modified cdrom.c to expose metadata read/write functions, and changed chdman to use them. Also changed chdman to parse old-style metadata and convert it to new-style metadata. Aaron Giles added new function core_fload() to load a file into an allocated buffer. Updated src2html, regrep and chdman tools to use this function where appropriate. Updated CHD hashes [Yasuhiro Ogawa, Aaron Giles, David Haywood]. Aaron Giles fixed bug where chdman -extract would not truncate to the logical size. NOTE: The CHD format has undergone a change with this release. The main reason for this change is to include some of the key metadata into the hashes for the CHDs. This ensures that the metadata is valid and prevents abuse. The first impact you will find is that all of your CHD differencing files are invalid. Just delete your "diff" directory contents entirely. The second impact is that all your existing CHDs will warn you that they have incorrect hashes. This is expected. Your old CHDs should still work fine, so if you can live with the "bad ROM" warnings, you don't really need to do anything. However, if this bugs you or you want to be "clean", you can update your CHDs, using this command line:  chdman -update <chdfile> <newchdfile> for each one of your CHDs. This will take a while, but will produce CHDs that match the new checksums posted in the drivers.
- 0.130              : Allow CHDs to be directly in the rom directory without a subdirectory [Olivier Galibert].
- 0.129u6            : Aaron Giles added flags to the CHD metadata entries, encoded in the top bit. Right now it is a no-op, but eventually will be used to indicate which bits of metadata are included in the overall checksum.
- 0.127u1            : Aaron Giles fixed corrupt CHDs are reported as missing.
- 0.127              : ElSemi included support for parsing .gdi files in CHDMAN.
- 0.126u4            : Aaron Giles removed per-frame metadata support from chdman. Creating an A/V now simply requires an AVI file input. Aaron Giles fixed bug in winwork that caused the creation of single work items to return NULL, and thus lead to massive memory leaks when using A/V CHDs. Disks opened by the romload module are no longer identified by index. Instead, they are identified by the region they were loaded in. This generally means one disk per region. get_disk_handle() now takes a region name in place of an index. Updated all callers to do this. The SCSI modules in particular posed a challenge to make this work, so watch out for potential bugs there [Aaron Giles]. Aaron Giles added new option to chdman, where if you use -createav with a special filename (either 2:2 or 3:2) it will create a fake laserdisc files with the equivalent cadence. This can be used for testing until full captures are available. Most games used 2:2 apart from Dragon's Lair and Space Ace, which were 3:2. Note that even though these files are essentially blank, they are Huffman-compressed, meaning that the maximum compression ratio you will get is 8:1, so they still end up ~5GB. Aaron Giles moved error strings from chdman.c to chd.c, where they can be fetched from any caller via the new chd_error_string() function.
- 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.128u2            : R. Belmont fixed wrong sector size at CD_TRACK_MODE2 conversion routine.
- 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.130u4            : Derrick Renaud fixed analog settings to return to default when IPT_UI_SELECT (enter) pressed. Fixed misplaced brackets, allowing upper/lower case extensions for crosshair graphics and ldplayer chd files.
- 0.130u1            : Vas Crabb fixed build of ldplayer on OS X. Since the CUSTOM sound module no longer exists, I arbitrarily changed it to WAVE, as ar gets upset if it has no input files. I also removed the -all_load flag for ldplayer from the main makefile as it upsets the linker on OS X.
- 0.129              : Laserdisc player works again. Added MDRV_LASERDISC_GET_DISC callback hook which allows for dynamically finding the CHD, rather than relying on the DRIVER_INIT hackery that was there before [Aaron Giles]. Oliver Stoeneberg cleaned up some memory and file handles in the error cases of ldverify. Aaron Giles fixed wrong colors using Direct3D on ATI cards.
- 0.128u7            : Aaron Giles modified laserdisc players to walk back to their global device state via the owner, rather than brute-force searching for the first instance and hoping that is the right one.
- 0.128              : Added tools\ldresample.c. Aaron Giles added new tool ldresample to assist in resynchronizing audio tracks in a CHD with frames. Currently still WIP but useful if you know what you're doing.
- 0.127u7            : Aaron Giles added new functions for building device-relative tags. Changed machine configuration builder to use these functions. Also changed the laserdisc player devices to use them. Updated Z80 CTC/SIO code to assume that the CPU provided for the clock is relative to the device that the CTC/SIO belong to. Updated memory code to assume that regions and devices referenced by the memory map are relative to the device the associated CPU belongs to. Aaron Giles cleaned up and normalized the three existing laserdisc emulations. Removed obsolete code from the laserdisc core.
- 0.127u6            : Aaron Giles removed render_container_set_palette_alpha() hack. Now the alpha value can be set directly in the palette entry and will be respected for laserdisc overlays. ldverify improvements [Aaron Giles]: Uses back-end decoding for CHDs directly to bitmaps. Changed min/max detection to only check 0/255. Fixed off-by-one bug in min/max computation. Separated white code detection from frame number detection. Track cadence with frame numbers as well as white codes. Use vbiparse.h constants where appropriate. Aaron Giles simplified core deinterlacing logic based on availability of pre-decoded VBI data. Added plumbing for allowing for overall brightness/contrast/gamma corrections on laserdisc video. Fixed bug when combining brightness values in the palette logic.
- 0.127u5            : Added machine\ldvp931.c. Removed machine\laserdsc.c. Aaron Giles added Philips 22VP931 laserdisc emulation, which is mostly working. Communication works fine and basic searching/playback/skipping is functional. Still a bit glitchy.
- 0.127u4            : Aaron Giles changed requirements for laserdisc CHDs to require a new chunk of metadata with pre-decoded frame information. Modified chdman to automatically produce this for CHDs that are of the appropriate parameters. To fix up existing CHDs, use chdman -fixavdata on the CHD. Aaron Giles modified the laserdisc core to leverage the pre-decoded frame metadata, which is now required. This improves seek times when searching and allows the player-specific emulation access to the VBI data as soon as it would really be available. Changed update callback timing to fire just before the first line of VBI data would be read; at that point, the frame selection is assumed to be committed. Aaron Giles changed laserdisc video parameters to position the screen area at the bottom rather than the top, since this corresponds more closely to standard line numbering. Aaron Giles extended the vbiparse code to support pack/unpack, and to more fully document all the meanings of the VBI codes. Aaron Giles updated ldplayer to support slow/fast forward movement, frame/chapter display and separate controls for scanning/stepping. Aaron Giles converted Simutrek-hacked laserdisc emulation to using the actual MCU from the game, which in turn hands off commands to the PR-8210 MCU. This is still not 100% but is pretty close at this point and achieves the correct behaviors in most cases.
- 0.127u3            : Aaron Giles extended the LD core interface structure to allow each player type to provide its own ROM region and partial machine driver. Aaron Giles changed laserdisc interface to explicitly specify the screen and sound devices it should route to. Drivers no longer have to manually call laserdisc_vsync(). Instead, the laserdisc code connects up to the routed screen device and works based on that screen's VBLANK timing. Removed all existing calls to laserdisc_vsync(). Aaron Giles changed laserdisc behavior so that it completes the previous video read and initiates the next read at the end of VBLANK instead of the beginning. This gives player logic time during VBLANK to alter the slider position prior to fetching the next frame. Aaron Giles added new laserdisc callback for vsync begin and changed the update callback to be called at the end of VBLANK. Also added functions to set the slider speed, advance the slider, and directly control the video/audio squelch. In addition, there is a new status function to get the slider position in general terms.
- 0.127u2            : Added machine\ldcore.c/h, ldv1000.c. Aaron Giles split core laserdisc functionality into separate file ldcore.c. Each player now gets its own source file, along with new hooks which enable more precise control over the behavior. Updated the PR-8210 and LD-V1000 implementations to the new spec. Other players will come online shortly. Aaron Giles changed laserdisc scan behavior so that it requires a constant stream of signals to continue scanning. Updated ldplayer accordingly.
- 28th August    2008: Aaron Giles - About Laserdiscs, part 3: As I mentioned previously, laserdiscs directly encode and reproduce the broadcast signal format (either NTSC or PAL). So in order to understand how the information about frame numbers and other details are encoded, it is important to know the basics of the underlying signal format. In this case, I'll talk about NTSC specifically. An NTSC frame consists of 525 scanlines of data, broadcast 29.97 times per second. As I mentioned before, each frame consists of two fields, which makes each field 262.5 scanlines (yes, it is true that there is an extra half-scanline). Of these 262.5 scanlines, only 240 are normally visible. This is because your classic CRT-based TV set required some time to move the electron beam from the bottom-right of the screen back to the upper-left in preparation for the next field, and 22.5 scanlines' worth of time was decreed to be an appropriate timeframe for this to happen. These extra 22.5 scanlines each field are known as the Vertical Blanking Interval, or VBI. Traditionally, there is not much of interest transmitted within the VBI area of the field, apart from a few basic control signals that were used for calibrating the picture and synchronizing the timing. Over time, however, people came up with reasons to add useful data to the VBI area. One of the most well-known of these is Closed Captioning, which is encoded on line 21 of each field (the top 22 lines are the VBI, and the following 240 are the visible lines). Laserdiscs took this a step further, and defined special encodings of their own. Line 11 of each field contains what is known as the "white flag", which is a simple binary indicator of whether the current field is the first field of a frame. Laserdisc players look for this white flag to know how to do a still frame that doesn't consist of a split between two film frames. Since it takes two fields to make one frame, and since many film-based laserdiscs are encoded in a 3:2 cadence, it is not straightforward to ensure this without some additional information. Even more interesting than the white flag are the "Philips codes" that are encoded on lines 16, 17, and 18 (note that all the laserdisc encodings are on lines different from Closed Captioning, so that laserdiscs could be encoded with Closed Captioning data as well). The Philips codes are special 24-bit digital values that are encoded in the VBI area of each field, and which are used to describe the field. In general, there are up to two Philips codes encoded on three lines, with line 17 generally being a redundant copy of line 18 for added resilience against dropouts or other transmission errors. So how do you encode a 24-bit binary number into a single scanline of an analog video signal? The answer is to use an encoding technique known as Manchester codes. If you treat bright white as a '1' bit, and black as a '0' bit, then this encoding uses two bits to encode each bit of the code. The reason for two bits is to ensure that the decoded value makes sense, and also to establish a clock for the codes. This works because Manchester codes encode a '0' bit as 10 and a '1' bit as 01. Because of this, you are guaranteed that in the middle of each bit there is a transition from black to white or vice-versa, and this can be used to establish the clock. Once you figure out the clock, then the direction of each transition tells you what the actual value of the bit is. Below is a picture of the VBI region for a CAV laserdisc. The top few rows are an ugly green because those lines of VBI data were not provided by the capture card. Once the Philips codes are extracted, they can be treated as binary data and evaluated. Unfortunately, it seems as though most of the information about what the various Philips codes mean has been kept relatively secret. However, the most important codes are understood: $88FFFF = Lead-in code (indicates the field is located before the official start of the disc), $80EEEE = Lead-out code (indicates the field is located after the official end of the disc), $FXXXXX = Frame code (specifies the 5-digit frame number (XXXXX) in BCD format), $8XXDDD = Chapter code (specifies the 2-digit chapter number (XX) in BCD format) and $82CFFF = Stop code (indicates the player should pause at the current field). So as the player reads data from the disc, it also needs to detect the white flag and Philips codes, and act on them as necessary. By capturing the VBI data along with the normal active video, we are able to preserve this information, and write a laserdisc simulator that operates off of the same information that the original players did.
- 0.127              : Aaron Giles added new generic laserdisc VIDEO_UPDATE handler to the laserdisc code. This handler works for both disc-only games and those with overlays. For disc-only games, the base macro is sufficient. For games with overlays, an additional set of configuration macros are provided: MDRV_LASERDISC_OVERLAY - specifies update function, width, height and bitmap format of the overlay, MDRV_LASERDISC_OVERLAY_CLIP - specifies the visible area of the overlay bitmap, MDRV_LASERDISC_OVERLAY_POSITION - specifies default x,y position and MDRV_LASERDISC_OVERLAY_SCALE - specifies default x,y scale factors. The update function provided to MDRV_LASERDISC_OVERLAY is identical to a normal VIDEO_UPDATE callback, so a standard one can be used. All existing laserdisc drivers have been updated to support this new rendering mechanism, removing much duplicated code. Aaron Giles added new macros MDRV_LASERDISC_SCREEN_ADD_NTSC and _PAL, which defines a standard screen with the correct video timing characteristics and update function for laserdiscs. Updated all drivers to use these macros instead of defining their own screens. Aaron Giles added DISK_REGIONS to all laserdisc drivers. Aaron Giles added DISK_IMAGE_READONLY_OPTIONAL to support games (like Cube Quest) where the disk is non-essential to the game's operation. Aaron Giles fixed bug in identifying the custom sound driver for the laserdisc. Aaron Giles updated ldverify to identify blank regions of the disc for post-processing. Aaron Giles fixed rendering 16bpp with alpha using bilinear filters (fixes screenshots of laserdisc games with overlays).
- 0.126u5            : Added ldplayer\ldplayer.c, ldpdriv.c and ldplayer.mak. Aaron Giles added new target ldplayer, which is based on MAME but serves as a standalone laserdisc player for CHDs. Right now only the Pioneer LD-V1000 is connected, and limited commands are available. Each player type is a driver, so you specify the player type on the command-line. The driver then opens the first CHD it finds in your ROM path and uses that as the laserdisc. The intention is that you specify the -rompath each time on the command-line, so a typical approach might be: ldplayer ldv1000 -rompath j:\mach3 , where it will pick up the mach3.chd lurking in your j:\mach3 folder. Several basic commands are supported: Space = play/pause, Alt   = toggle frame display, Left  = scan forward (when playing) or step forward (when paused), Right = scan backward (when playing) or step backward (when paused), 0-9   = enter numbers for search and Enter = execute search to frame. Aaron Giles rejiggered huffman.c to support multiple interleaving streams and a delta-RLE pre-encoding. Added optimized case for the Y/Cb/Y/Cr video encoding case. Cleaned up the code. Aaron Giles updated avcomp.c to use the new huffman.c functions. Reworked configuration options to allow for both input and output of naturally aligned data streams. Updated chdman and laserdsc to use the new interfaces. New compression gives an additional 3-7% over previous attempt and compresses the dummy CHDs down significantly. Aaron Giles added video level detection and reporting to ldverify. Aaron Giles forced a sound synchronization on each vsync in the laserdisc playback. This prevents overwriting the tail end of the buffer which was fouling up the MACH 3 audio decoding.
- 12th August    2008: Aaron Giles - About Laserdiscs, part 2: All known laserdisc-based videogames use CAV (constant angular velocity) laserdiscs, primarily because these discs could be manipulated in advantageous ways. Players of the era could seek to specific frames, play at different speeds, still frame, play backwards, and perform all sorts of other operations that were not possible with CLV discs. The reason this was possible is that on a CAV disc, each track corresponds exactly to one frame of video. There are approximately 54,000 tracks on one side of a CAV laserdisc, giving 54,000 frames of video per side. Now, believe it or not, laserdiscs are actually analog devices, meaning that the signal that is stored on them is analog, and is described exactly by the video transmission data standard of its intended country (NTSC or PAL, depending on where you live). Thus, once the data is read from the laserdisc, it is basically identical to the signal that you would receive over the airwaves for watching regular broadcast TV. Let's step back a moment and think about how laserdiscs of movies work. A movie is traditionally filmed at 24 frames per second. In contrast, the NTSC broadcast standard (which describes how video is transmitted in North America) describes the TV signal as running at 30 frames per second. Furthermore, each frame is built up of two "fields", which are drawn one after another at a slight offset. This is known as interlacing. Since there are two fields each frame, and the frames run at 30 per second, the result is that the individual fields are transmitted at twice that rate, or 60 times per second (in reality, it is 29.97 frames/second and 59.94 fields/second, but we'll stick to round numbers). So the question becomes, how do you reproduce a film, running at 24fps, within the NTSC standard, which runs at 30fps (or more precisely, 60 fields/second)? If you transferred one frame of film to one frame (two fields) of NTSC video, the result would play back at 30fps, or 25% too quickly. If you duplicated each film frame onto two frames (four fields) of NTSC video, the result would play back at 15fps, or 38% too slowly. The solution that engineers came up with many years ago was to realize that 60 / 24 = 2.5. That is, when you look at it in terms of fields instead of frames, each film frame should conver exactly 2.5 fields of NTSC video. However, since you can't split the video midway within a field, they chose instead to alternate between using 3 fields per film frame and 2 fields per film frame. So the first film frame will be duplicated onto the first 3 fields, while the second film frame will be duplicated onto the next 2 fields, and so on. This is known as 3:2 cadence. The important thing to realize out of all of this is that there was not always a 1:1 relationship between film frames and NTSC frames (though there often was, for example, when the laserdiscs contained video that was originally produced for broadcast TV). That is, if you wanted to view frame #1000 of the actual film, you could not necessarily just seek to NTSC frame #1000 and end up where you wanted. Instead you actually had to go figure out which NTSC frame corresponded to film frame #1000. When the laserdisc was designed, this discrepancy was actually taken into account. The designers realized that being able to seek to a given NTSC frame was actually not nearly as useful as being able to seek to a particular film frame, and so they devised a way to encode information about the frame numbers on the laserdisc itself. Which brings us back around to games. For years, laserdisc emulation has relied on "frame files" and "conversion equations" to determine how to map the film frames (which is what all the seek commands target) to NTSC frames (which is what you get when you capture video). But the information about which NTSC frame corresponds to which film frame was present all along in the video signal itself; we were just not aware of it, nor aware of how to capture it. In the next article, I'll talk about how this information is encoded.
-  7th August    2008: Aaron Giles - About Laserdiscs, part 1: Laserdiscs come in two varieties: CAV (constant angular velocity) and CLV (constant linear velocity). As its initials imply, a CAV laserdisc spins at the same speed no matter where on the disc it is being read from. Since laserdiscs play back at a fixed data rate, this implies that data is packed more tightly near the center of the disc than it is toward the outer edges. If you remember your basic geometry, the circumference of a circle is directly proportional to the radius (C = K × r). Let's say the disc spins just fast enough so that one rotation holds one video frame. So if you encode one frames' worth of data at r=5, you have to pack it into a linear distance of 5K. If you encode the same amount of data at r=8, you have much more room (8K) to store it in. In contrast, a CLV laserdisc packs its data at the same density regardless of its location on this disc. This means that in order to read it, a laserdisc player must adjust the rotation speed depending on how far away from the center of the disc it is reading. Compact discs are CLV devices and you probably recognize the disc speed changing as you seek back and forth. Back to the geometry, in CLV discs data is read at a constant rate (R) per unit of circumference (rate = R × C). Since the circumference is proportional to the radius, this makes the data rate proportional to the radius as well (rate = R × (K × r) = RK × r). This means that at r=5, the disc stores 5RK units of data, and at r=8, the disc stores 8RK units of data. It's pretty clear that CLV discs pack the data more efficiently than CAV discs. This is because with CLV discs, you can pack the data at the maximum rate the player is capable of reading consistently across the entire disc. Whereas with CAV discs, the data can be efficiently packed at the inner part of the disc, but as you move farther away from the center, it gets increasingly less densly packed. In reality, CAV discs maxed out at about 30 minutes (54,000 frames) of playback per side, while CLV discs generally got about 60 minutes per side. Given these facts, why on earth would you ever create a CAV disc, when a CLV disc allows you to pack the data more efficiently? Well, because the simplicity of finding information on a CAV disc enabled many special features: still frames, reverse play, slow motion, and - most importantly for laserdisc-based video games - direct access to any frame on the disc by index. With a CAV disc, each video frame happens to corresponds to one rotation of the disc. Thus, if you want to advance 100 frames ahead, you simply moved the laser up the appropriate amount and read the data there. On the other hand, with a CLV disc, advancing 100 frames involves knowing how fast the data is coming and computing where to seek and how much to adjust the rotation speed to find the target, a much more complicated maneuver. When it comes to movies, most laserdiscs were produced as CLV, to minimize the number of times you need to flip or change discs. A few special edition and high-end versions of movies were released as CAV, enabling access to nice still frames and other effects. When it comes to videogames, however, it's all CAV. In the next article, I'll ignore CLV discs entirely, and talk about tracks, frames, and VBI data on CAV discs.
- 0.126u4            : Added tools\ldverify.c. Aaron Giles added proper laserdisc support for MACH 3, Us vs. Them and Cobra Commander (MACH 3 hardware). Old laserdisc hacks are now removed. The code now talks to the standard Pioneer PR-8210 interface. Also removed hacky "target list" from the MACH 3 ROMs; this information is now decoded on the fly from the right channel laserdisc audio. Aaron Giles changed laserdisc support to parse white flags and other data from the VBI data directly, rather than relying on the textual metadata. Expanded video frame cache to 3. Changed the way frames are assembled to decrease the likelihood of getting an interlaced weave. Fixed sound creation so that it is done at reset time instead of device start, when the sound devices aren't yet live. Aaron Giles change the laserdisc interface to no longer require a disk number or a custom sound device. Both are now assumed to be tagged the same as the laserdisc device. Updated all drivers accordingly. Other laserdisc changes [Aaron Giles]: Changed PR-8210 interface to work consistently for both Gottlieb and Stern games. Added audio callback mechanism to allow drivers to peek at the raw audio streams. Aaron Giles removed obsolete makemeta tool. Replaced it with new ldverify tool which walks through either an AVI or CHD capture from a laserdisc and ensures that there are no anomalies lurking in the VBI data. Aaron Giles added new option to chdman, where if you use -createav with a special filename (either 2:2 or 3:2) it will create a fake laserdisc files with the equivalent cadence. This can be used for testing until full captures are available. Most games used 2:2 apart from Dragon's Lair and Space Ace, which were 3:2. Note that even though these files are essentially blank, they are Huffman-compressed, meaning that the maximum compression ratio you will get is 8:1, so they still end up ~5GB. Aaron Giles updated vbiparse to improve Manchester code decoding. It now assigns a confidence level per bit based on how solid the data is. Also added a new function vbi_parse_all which parses the white flag and all three lines of metadata from a laserdisc frame. It then compares line 17 and 18 against each other and selects the most likely candidate based on per-bit confidence and other factors. Aaron Giles added frame number display to laserdsc.c. It is off by default, though most players can be configured to turn it on (not sure if any actually do). It can be manually toggled via the backslash key during playback.
- 0.126u2            : Laserdiscs are now devices [Aaron Giles]: Updated all drivers accordingly.
- 0.126u1            : Added util\vbiparse.c/h. makemeta changes [Aaron Giles]: Split out Manchester code parsing into a separate utility module. Rewrote Manchester code parsing to be clock based. Updated tools\makemeta.c to call the new functions. Changed makemeta to parse a different format for metadata. Fixed Huffyuv decompression in aviio. Added more robust logic to parse out the white flag.
- 13th July      2008: Aaron Giles - DirectShow Part 2: A while back, when the initial push to start adding laserdisc support to MAME was happening, I discovered that there was something missing in all existing laserdisc captures. If you know anything about the NTSC broadcast standard, you know that a video signal consists of 525 scanlines spread across a 30Hz (actually 29.97Hz) interval. Of those 525 scanlines, 480 are considered to be "visible" scanlines, while the remaining 45 constitute the vertical blanking interval (VBI). At first, the VBI part of the scan just contained a couple of special signals for synchronization, but over time, people started adding data to them. The most famous example is closed captioning, which is usually encoded as binary data on line 21 of each video field (a single 30Hz frame is sent as two 60Hz fields, interlaced). Getting back to DirectShow, the way this is handled for video capturing is that the video capture component has a VBI output, which is the raw VBI data, usually sampled at a high rate (2x or 3x the video sampling rate) for improved accuracy. As with everything in DirectShow, there are filters that you can attech the VBI output to, which will decode the line 21 data into binary data, and then further filters that will render the captions as overlays on top of the video stream. The thing I discovered about laserdiscs, though, is that they encoded several very important bits of metadata on some of the VBI lines. Specifically, line 12 has what is known as a "white flag", line 16 contains some control bits, and lines 17-18 contain information about the current frame number and chapter. Even more importantly, all of this metadata is crucial to the way laserdiscs are controlled and operated in video games. The problem is, how do you capture that data? Well, you could route the raw VBI data to a file and then attempt to sync it up with your video capture. But an easier way to deal with it would be to simply take the VBI data, reconstitute it as video signal, and render it above the visible video signal, to essentially reproduce a capture of the entire video signal - all 525 lines of it. Sadly, such a filter didn't exist (or at least I was unable to find such a thing). But thankfully, the DirectShow architecture makes it a fairly simple matter to write your own, which turned into a little side project that I have been working on. Although not quite ready for prime time (synchronization is still a little tricky), the basic filter is now up and running, and we have some actual demo captures with the laserdisc VBI data intact:  (In the current version, I extract the laserdisc metadata and overlay it on the video as well, to see if the information matches up. The frame number that the laserdisc player decoded is in large text at the top, and the information my filter has decoded is displayed on the bottom, with field 1 info on the left and field 2 info on the right). In the end, I'll post the source and binary versions of this filter so that it will be possible to get consistent laserdisc captures complete with metadata (on Windows only, though similar techniques can probably be applied to other platforms). And yes, with this problem solved, they should be starting to happen in the coming months. 
- 12th July      2008: Aaron Giles - DirectShow: Had my first real exposure to DirectShow recently and I've come away pretty impressed. For those who don't know, DirectShow is an architecture inside Windows that is used for streaming and capturing media (audio/video). It works through a series of independent components, each of which has some number of inputs and outputs. These components can then be assembled as appropriate to route data through the system. (Note that I believe there is a successor to DirectShow, but since I'm an old-skool kind of person and wanted compatibility with other DirectShow components, I went that way). Components fall into three categories: sources, which only have outputs and provide source data; renderers, which only have inputs and "render" the final data; and filters, which have both inputs and outputs and transform the data in some way. Now, this might not seem all that impressive until you realize that the process of connecting components and building up a data flow has been completely abstracted. The key to this is the Microsoft-provided utility GraphEdit. What this simple utility does it allow you to add a bunch of filters and then interconnect them. You then hit "play" and the filters are activated. Assuming you have assembled the filters and connections between them properly, data flows from the source through the filters and to the renderer(s). As a super-simple example, you can take a still image (say, a JPG file) and make that your "source" via the Generate Still Video component. You can then route the output of that to a Color Space Converter filter which applys color transformations to the image. And then you can route the output of the filter to the "Video Renderer", which renders any video inputs to the screen in a window. Once you've built this graph, you simply hit "play" and up pops a window with the JPG image. Ok, that was super-simple, but you start to get the idea. The next step is to try changing the renderer to something else. Let's say we want to output an AVI file of this still image. We can do that by first connecting the output of the Generate Still Video source to one of the inputs of an AVI Mux filter (this filter accepts multiple inputs - usually a video stream and an audio stream - and interleaves them into a single AVI data stream). We then connect the output of the AVI Mux filter to a "File Writer" renderer, which lets us route the raw output of any filter to a file. Now when we hit "play", the still video source is converted to an AVI file. Let's say we want to both view the output AND generate an AVI file. No problem. We insert a new Smart Tee filter, which has one input and two outputs, each of which contains a copy of the input. Then we wire one output through the Color Space Converter and out to the Video Renderer to see what we are viewing, and we wire the second output through the AVI Mux and out to the File Writer. Hitting "play" now does both: an image and an AVI file. Now for the main event. Let's swap out the source with something more interesting. Say, the video capture component provided by your video capture card (each card is different, so I can't provide the exact details here, but you need to dig through all the filters to find them). Usually there are two pieces: a Crossbar source component, and a Capture filter component. Set up the Crossbar to output the appropriate source from your capture device, route that through the Capture component, and then route the outputs from there into the Smart Tee, which is still outputting to the screen and an AVI file. Hit "play" and now with nothing more than this GraphEdit tool, you have a video capture solution. Granted, it's a bit bare bones (some components have property panels you can get at via a right-click), but it works. And the ability to wire up the filters comes in handy in a major way.
- 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, ldcore.c, ldv1000.c and ldpr8210.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 22VP931                 Fire Fox (Atari 1984)
        Philips 22VP932                 Space Ace (Cinematronics 1983 European), Dragon's Lair (Cinematronics 1983 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 (Stern 1983)
        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/



I12.61  Pioneer PR-8210

- 0.127u7            : Aaron Giles and Warren Ondras added correct overlay positioning, font and behavior to PR-8210 emulation. Aaron Giles cleaned up and normalized the three existing laserdisc emulations. Removed obsolete code from the laserdisc core.
- 0.127u4            : Aaron Giles converted PR-8210 emulation over to using the actual MCU from the laserdisc player. This MCU controls low-level functions such as slider position and laser on/off, and receives decoded vertical blanking data in order to make decisions. Removed old HLE behavior. Note that the overlay text is displayed via the UI; this is temporary and will be fixed shortly.
- 0.127u3            : Added ldplayer\layout\pr8210.lay. Aaron Giles moved preliminary PR-8210 emulation code from ldplayer.c to ldpr8210.c. It is currently disabled behind the EMULATE_PR8210_ROM compile time flag. Aaron Giles further updates to the PR-8210 ROM simulation. Still not quite there but the system is much better understood now. Added layout to the PR-8210 which displays the state of the front-panel LEDs.
- 0.127u2            : Added machine\ldpr8210.c. Aaron Giles split core laserdisc functionality into separate file ldcore.c. Each player now gets its own source file, along with new hooks which enable more precise control over the behavior. Updated the PR-8210 and LD-V1000 implementations to the new spec. Other players will come online shortly. Aaron Giles changed laserdisc scan behavior so that it requires a constant stream of signals to continue scanning. Updated ldplayer accordingly.
- 0.127u1            : Aaron Giles added PR-8210 support to the ldplayer. Fixed step forward command on the PR-8210. Aaron Giles added some initial logic to boot and run the PR-8210 ROM (i8049) in ldplayer.c. Currently this is disabled behind a compile-time switch. Once this is working, the plan is to incorporate this into the existing PR-8210 emulation, but we're not there yet.
- SOURCE: machine\ldpr8210.c
- NOTES: Pioneer PR-8210A LaserDisc Player.



I12.62  Pioneer LD-V1000

- 0.127u7            : Aaron Giles added preliminary LD-V1000 emulation. Not fully working yet, but mostly there. Aaron Giles cleaned up and normalized the three existing laserdisc emulations. Removed obsolete code from the laserdisc core.
- 0.127u6            : LD-V1000 [Aaron Giles]: Added some (compile-time removed) information about the ROM and memory map.
- 0.127u2            : Added machine\ldcore.c/h, ldv1000.c. Aaron Giles split core laserdisc functionality into separate file ldcore.c. Each player now gets its own source file, along with new hooks which enable more precise control over the behavior. Updated the PR-8210 and LD-V1000 implementations to the new spec. Other players will come online shortly. Aaron Giles changed laserdisc scan behavior so that it requires a constant stream of signals to continue scanning. Updated ldplayer accordingly.
- 0.126u5            : Aaron Giles added new target ldplayer, which is based on MAME but serves as a standalone laserdisc player for CHDs. Right now only the Pioneer LD-V1000 is connected, and limited commands are available. Each player type is a driver, so you specify the player type on the command-line. The driver then opens the first CHD it finds in your ROM path and uses that as the laserdisc. The intention is that you specify the -rompath each time on the command-line, so a typical approach might be: ldplayer ldv1000 -rompath j:\mach3 , where it will pick up the mach3.chd lurking in your j:\mach3 folder. Several basic commands are supported: Space = play/pause, Alt   = toggle frame display, Left  = scan forward (when playing) or step forward (when paused), Right = scan backward (when playing) or step backward (when paused), 0-9   = enter numbers for search and Enter = execute search to frame. Aaron Giles rejiggered huffman.c to support multiple interleaving streams and a delta-RLE pre-encoding. Added optimized case for the Y/Cb/Y/Cr video encoding case. Cleaned up the code. Aaron Giles updated avcomp.c to use the new huffman.c functions. Reworked configuration options to allow for both input and output of naturally aligned data streams. Updated chdman and laserdsc to use the new interfaces. New compression gives an additional 3-7% over previous attempt and compresses the dummy CHDs down significantly. Aaron Giles added video level detection and reporting to ldverify. Aaron Giles forced a sound synchronization on each vsync in the laserdisc playback. This prevents overwriting the tail end of the buffer which was fouling up the MACH 3 audio decoding.
- 0.111u5            : Aaron Giles added support for the custom Badlands commands to the LD-V1000 emulation.
- 0.110u4            : 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.
- SOURCE: machine\ldv1000.c


I12.63  Philips 22VP931
- 0.127u7            : Aaron Giles cleaned up and normalized the three existing laserdisc emulations. Removed obsolete code from the laserdisc core.
- 0.127u5            : Aaron Giles added Philips 22VP931 laserdisc emulation (Fire Fox), which is mostly working. Communication works fine and basic searching/playback/skipping is functional. Still a bit glitchy. smf removed sprite to tile priority in Fire Fox, it doesn't exist.
- 28th January   2003: smf sent in a preliminary Fire Fox driver written by him and Chris Hardy, but the laserdisc emulation has not been done yet so there's not much to see.
- SOURCE: machine\ldvp931.c






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.128u7            : Aaron Giles renamed REG_PC -> REG_GENPC, REG_SP -> REG_GENSP and REG_PREVIOUSPC -> REG_GENPCBASE. Updated a few spots that were using these directly. Moved these definitions into the end of the register area rather than leaving them outside which put them in a weird range.
- 0.126u5            : Moved mame\machine\pcshare.h to emu\machine\pcshare.h.
- 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
  5.66  06B49P

  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.128u3            : Couriersud changed 74123 into a device. Clarified behavior from datasheet. Added logic to avoid recursive calls.
       - 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.
       - 0.36RC1            : Added machine\74123.c/h.
       - 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.129              : MooglyGuy added savestate support to the TTL74148 device.
       - 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.129              : MooglyGuy added savestate support to the TTL74153 device.
       - 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)


       74LS174/175
       - 0.127u1: Couriersud added a new generic latch device. Generic emulation of 74LS174/175, 74LS259 and other latches. Apart from providing synched latch operation, these latches can be configured to read their input bitwise from other devices as well and individual bits can be connected to discrete nodes. Please see audio/dkong.c for examples.


       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)

       74LS259
       - 0.127u1: Couriersud added a new generic latch device. Generic emulation of 74LS174/175, 74LS259 and other latches. Apart from providing synched latch operation, these latches can be configured to read their input bitwise from other devices as well and individual bits can be connected to discrete nodes. Please see audio/dkong.c for examples.

       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)
       1855      RCA CDP1855CDX 201                  8-Bit Programmable Multiply/Divide Unit (Lgp)
       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)


       MC3340
       - 0.127u1: Derrick Renaud added discrete sound for Starship 1. Still need to properly emulate the MC3340.
       - NOTES: The Motorola MC3340 VCA chip has logarithmic control response. Because it is designed for single supply operation, the output has a DC offset of about half the supply voltage. An op-amp is used to get the control voltage range to 1  10 volt. This circuit has very low distortion at moderate signal levels and low signal bleedthrough. But the CV bleedthrough is far too high for synth use. Another problem is that it won't produce 10 V p-p output level. You could add another op-amp at the output to fix this and the DC-offset. But then you would lose the main advantage with this chip, which is low parts count.


       SM7831
       - NOTES: The NPC SM7831 is a CMOS-LSI arithmetic processor developed for decimal long-word arithmetic. This LSI functions as the arithmetic co-processor and dramatically improves the cost performance of a microcomputer. Freatures: High-speed execution of decimal arithmetic operations, such as addition, subtraction, multiplication, division and square root extraction.
       - NOTES: NPC = Nippon Precision Circuits
       - GAMES: Lucky 74 (Wing 1988)



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

- 0.127u5            : Aaron Giles added generic timer devices, which simply allocate a timer but don't prime it. This is the preferred method for allocating timers and may eventually be the only mechanism for doing so in the future.
- SOURCE: emu\timer.c


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            : Phil 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.128u6            : Wilbert Pol added MDRV_PIT8253_ADD macro. Also, writes to a pit8253 timer control word always restart the timer.
- 0.126u4            : Wilbert Pol set the initial 8253 timer output to 2 to indicate that it is undetermined.
- 0.126u1            : pit8253 updates [Wilbert Pol]: Changed the implementation to use timers internally. Removed the frequency change callbacks.
- 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
- DRIVERS: filetto.c, gamecstl.c, mediagx.c, taitowlf.c, tiamc1.c and vertigo.c
- PCB: NB5K8253 (LaserBase)


O2.8   8254
- 0.128u6            : Wilbert Pol added MDRV_PIT8254_ADD macro.
- 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
- 0.36b3             : Added machine\8254pit.c/h.
- 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.127u2            : Barry Rodewald added basic implementation of the "update ended" interrupt flag to the 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 + ksys573.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             : Added machine\pd4990a.c/h. 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.129u4            : Couriersud fixed the MSM6242 RTC ignores AM/PM bit.
- 0.125u1            : Dirk Best fixed crash in Dynax games due to missing MSM6242 device.
- 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

O5.66  06B49P
-NOTES: The 06B49P IC is a programmable clock divisor. It provides every frequency needed for all devices from this hardware, plus V-Sync, H-Sync and (V+H)-Sync (composite) frequencies. All generated clocks are proportional to the Clock In (12MHz). There are not fixed or harcoded frequencies.
- PCB: 06B49P, DIP28 (Countrun, Freekick, Lucky74)







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.129u5: Device-ified the Atari mathbox [Couriersud]. Device-ified the Atari vector generators [Couriersud].
       - 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)


       WIP:
       - 0.128u6: Atari Ace fixed the widely used deco16ic video core to no longer reference the global Machine.
       - SOURCE: video\deco16ic.c



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.130u3            : Added includes\konamipt.h.
       - 0.128u6            : Atari Ace fixed the widely used konamiic video core to no longer reference the global Machine.
       - 0.125u7            : GX era hardware [Yasuhiro Ogawa]: Update video parameters to use actual values written to the CCU.
       - 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.
       - 0.36b2             : Added vidhrdw\konamiic.c/h.
       - 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.125u4            : Fixed crasher due to some Konami games using 8 layers in the K056832 implementation, even though it was only written for 4 [Aaron Giles].
       - 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


       NVC285       DIP28             (Puckman, Rally X, Dodgem)      Z-80 Sync buss controller. Can be replaced by plug-in board A082-91383-B000
       NVC293       DIP18             (Rally X)                       Video shifter. Can be replaced by plug-in board A082-91388-A000.


       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
       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.


       Acorn Archimedes custom chips
       - 0.129u3: Added machine\archimds.c/h and aristmk5.c driver. R. Belmont imported Archimedes code from MESS.
       SOURCE: machine\archimds.c


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-5313: -  1st June 2008: Charles MacDonald - Here is a mostly complete pinout for the 315-5313 VDP: http://cgfm2.emuviews.com/txt/vdppin.txt . If anyone does something cool like sticking a RAMDAC chip on the color bus outputs, do let me know.
       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:
       - 0.128u6            : Atari Ace fixed the widely used taitoic video core to no longer reference the global Machine.
       - 0.123u4            : Zsolt Vasvari fixed Taito Custom ICs (taitoic) regression that caused crashes in several games.
       - 0.37b5             : Added vidhrdw\taitoic.c/h.
       - SOURCE: emu\video\taitoic.c

       TC0100SCN
       - 0.125u2            : Phil Bennett fixed black pixel patches present in the TC0100SCN fg layer of Under Fire and Ground Effects.
       - 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.


       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
- 14th August    2008: Tomasz Slanina - The best implementation of s2636 i've found so far is part of the MESS vc4000 driver. I'll try to "borrow" some code and test. But the main problem remains - how to emulate 3 chips at the same time? Uhh .in fact it's easy to emulate them, like other drivers does, just no interaction / communication between them. In fact they are "chained" somehow. According to datasheet there's possibility for use of mutliple PVIs. But no details. Also the game Galaxia reads external i/o port (instead memory mapped to PVIs )to check ship - enemies collisions.
- 0.126u5            : Tomasz Slanina fixed ROM mapping and added preliminary video emulation to Galaxia.
- 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)
- WEB: http://mess.toseciso.org/datasheets:signetics
- 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
- 0.128u6            : Introduced function macros for ANTIC_RENDERER. Pushed the running_machine * passing through these functions. In other locations added "running_machine *machine = Machine" to the top of functions to isolate the dependencies [Atari Ace].
- 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.128u2            : Atari Ace added missing const/statics, added/removed entries in header files, and fixed a few potential multisession issues by explicitly adding initializers. asic65.c has significant changes to accomodate using a struct instead of 16 variables, otherwise the changes are modest and obvious.
- 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.130u4            : Nathan Woods changed the PPU2C0x implementation to be a device.
- 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


- 0.129u5            : Atari Ace fixed crash/freeze while starting games using segaic16.
- 0.128u6            : Atari Ace fixed the widely used segaic16 video cores to no longer reference the global Machine.
- 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

- 0.130u1            : Minor video/psx.c changes that were needed for raycrisis [David Haywood].
- 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.128u6            : Voodoo devices now require a CPU to be defined in the configuration in order to know whom to steal cycles from or stall when FIFOs get full. Updated all voodoo users to specify one [Aaron Giles].
- 0.125u7            : Aaron Giles converted Voodoo into a proper device. Updated drivers accordingly. Added save state support to the Voodoo emulator. Fixed poor default CLUT handling in the Voodoo driver.
- 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
- 0.113u3            : Aaron Giles fixed bug in voodoo emulation that caused improper framerates to be computed.
-  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.129u4            : Removed emu\video\cdp1869.c. Cidelsa changes [Curt Coder]: Combined CDP1869 video and sound parts to one device.
       - 0.129u1            : Curt Coder fixed sloppy rendering in CDP1869 that caused occasional crashes.
       - 0.128u6            : CDP1869 devices now also require a CPU to be defined in the configuration, in order to know which CPU's registers to fetch. Updated all cdp1869 users to specify one [Aaron Giles].
       - 0.125u2            : Curt Coder fixed CDP1869 character memory access, and Cidelsa sprite flashing.
       - 0.124u4            : Curt Coder added a macro for the CDP1869 interface, and made write handlers optional.
       - 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 [Peter Trauner].
       - 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.129u2            : Wilbert Pol force recalculation of screen parameters when only the MC6845 input clock changes.
       - 0.129              : Phil Bennett correctly setup the MC6845 device in the calomega, carrera, coinmstr, funworld, goldnpkr, rockola and usgames drivers. This fixed games crashed with an error on startup before OK.
       - 0.128u4            : MC6845 Hsync needs to toggle on every scanline [Curt Coder]. This fixed games using the MC6845 displaying the message "Mode Control 88 is not supported!!!".
       - 0.128u3            : Curt Coder reverted MC6845 changes as they broke a number of things. This fixed crash/hanging in many games using the MC6845.
       - 0.128u2            : Curt Coder fixed skewing and display area in MC6845.
       - 0.128u1            : MC6845 changes [Curt Coder]: Added cursor and display enable skewing. Added preliminary support for SY6545-1's transparent addressing mode. Hsync should be pulsed even when vsync is active.
       - 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 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. Changed MC6845 to take a screen tag instead of a screen number. Fixed flickering in Electric Yo-Yo. Changed qix driver to use the MC6845's VSYNC notification for interrupts. Added some new 6845 varieties: MC6845-1, H46505, HD6845 and SY6545-1.
       - 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 vidhrdw\crtc6845.c/h. Added Motorola 6845 CRT Controller interface driver (video\crtc6845.c)
       SOURCE: video\mc6845.c


       HD63484
       - 0.129u5            : Robiza impemented CRCL command in HD63484 (used in skattv test mode).
       - 0.129u4            : Phil Bennett added Read Parameter Register support to the hd63484. Moved logging behind a define.
       - 0.127u1            : HD63484 improvements [Robiza]: Fixed cpx and cpy when a ptn or a agcpy command is executed. Fixed for PTN command: copy direction and dot color. First implementation of PAINT command (for now only 4bpp and 8bpp supported and the pattern is not supported).
       - 0.127              : Robiza improved HD63484 core to support some initial graphics.
       - 0.126u5            : Added video\hd63484.c/h. Some improvements to shanghai video drivers [Robiza]: Convert framebuffer's ram from 8 bit to 16 bit. Convert dma command from 8 bit to 16 bit. Convert gfx command from 8 bit to 16 bit. Implemented all gfx mode: 1,2,4,8,16 bpp. Now we can use this gfx chip for adp driver that use 4bpp.
       SOURCE: video\hd63484.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)



       TMS9927
       - 0.131: Added video\tms9927.c/h. Aaron Giles added basic implementation of the TMS9927 video controller.
       NOTES: The video controller registers effect screen size (before hard-coded on a per-game basis in MAME). SOURCE: video\tief.c
       GAMES: Pacific Novelty - Shark Attack (1980), Thief (1981), NATO Defense(1982)
       SOURCE: video\tms9927.c


       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.128u6            : Atari Ace modified the tms34061.h interface to eliminate some more global Machine variables. More deprecat.h includes eliminated.
       - 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 vidhrdw\tms34061.c/h. Added TMS34061 video controller.
       SOURCE: emu\video\tms34061.c


G5.8   Other

       06B53P       The 06B53P IC is a custom video controller. The Lucky 74 PCB has two of them. Each one handle one graphics bank, the respective video (and color) RAM, and switch the dual-state color circuitry to generate its own palette. 
       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)
       UM70C178     UMC UM70C178 HiColor RAMDACs, 256 x 18 Bit Colorpalette with 3x 6-bit DACs (Cheesech)


       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

- 29th January   2009: Model 2 Emulator v0.9 Final: Fixed TGP emulation bugs and added missing opcodes. Virtua Fighter 2 and Virtua Cop 2 are now playable. There is still a bug with VF2 hair/body collisions, probably another TGP bug, but it's quite hard to find... * Fixed I960 bug that caused daytona invisible walls/holes in the road. * Fixed timer bug that caused missing hair in Fighting vipers, tails in sonic and slow cars in Sega Rally (although they still don't work properly). * Added support for "return to neutral". Enable it with HoldGears=1 option in emulator.ini. This setting will cause the emu to return to neutral when no gear button is pressed. * Redone rasterizer color decoding and texture mapping. Now it works the same way the real hardware does, performing all the same table lookups and calculations, so color should be accurate now. The color decoding is now done at pixel shader level so you'll need a PS 2.0 capable video card in order to run the emulator now. * Fixed white borders in some transparent textures. * Redone texture caching code. Improved dirty texture detection. Fixes wrong textures in some games when a new texture overlaps partially with an existing one. * Changed ManxTT sound roms to the Twin ones. The previous romset was using the Deluxe ones that have 2 sound boards. Fixes the "japanese speech when braking" bug :).Set the machine to Twin. * Added 2 mice support for shooting games. Enable it with RawInput=1 in emulator.ini. Read some other options there to tell the emu how to map a mouse to a player. When using RawInput the mouse will be locked to the emulator window. In order to switch to another window, either press Alt to bring the menu and unlock the mouse or use Alt-Tab to switch to another application. * Fixed Alt key not activating the window menu. * Fixed MB86235 bug when handling denormalized numbers that caused top skater and overrev lock the emu sometimes. * Fixed corrupt textures sometimes when loading a savestate. * Fixed frameskipping bug that caused some data not being updated in the TGP memory when frameskipping (daytona windows not updating windows after entering/leaving the tunnel). * Added an option to hide the crosshair in shooting games (DrawCross=0 in emulator.ini). * Fixed Daytona to the maxx rom loading that caused wrong and missing graphics. * Improved FM emulation support to the SCSP for some HOTD tunes requiring it. * Fixed various bugs in the new MultiPCM sound emulation, causing some wrong loops and sounds. * Fixed meshed transparencies size. Now they will scale to the selected resolution. * Fixed specular highlights calculation. * Added Daytona USA '93 edition and Daytona USA: GTX 2004. * Added Rail Chase 2. * Added Virtua Cop 2. * Added Virtua Fighter 2, Rev A, Rev B and 2.1. * Added Sega Water Ski. The current sound rom dump seems to be bad so the game will run without sound. This game will start in Japan region mode. To change the region, enter Test menu (F2) and press the sequence up,up,down,down,service (f1),test (f2). * Added Indianapolis 500 Rev A. * Changed romsets to match MAME as much as possible.
-  6th December  2008: Model 2 Emulator v0.9 WIP - Peabo: The bug with the strange textures near the edge of the road on the expert course of Daytona is fixed. I did a complete redump of the Daytona rom, and it turned out to be identical to the current dump, byte for byte. So it was not due to a bad dump after all, and ElSemi fixed it very quickly. This is good news for anyone worried about needing yet another version of the Daytona rom.
- 28th November  2008: Model 2 Emulator v0.9 WIP - Peabo: Daytona needs to be redumped for 0.9 as it turns out that the ROM everyone has been using all this time is actually a bad dump and has some corrupted textures on the Expert track. If you look at the apex as you exit the difficult building-turn at the start of the track, it becomes a squished version of the road texture. This also happens intermittently around the track on other turns. I checked it compared to the boards and it's definitely a result of a bad dump.
-  9th November  2008: Model 2 Emulator v0.9 WIP - Lucisac: The Model 2 Emulator BETA4 brings significant improvements over BETA3 bringing emulation of Model 2 hardware to the next level. Changes include a set of new features, new games and revisions, graphical improvements, audio improvements and many bug fixes both in the major and minor categories. New Features: Dual mouse support for shooting games (via new .ini entry "UseRawInput"). The crosshair can now be set on and off (via new .ini entry "DrawCursor"). New Games: Daytona USA GTX2004, Indianapolis 500 Deluxe Rev A and Top Skater (USA). Improvements: The colour tables have been correctly emulated resulting in accurate colour reproduction for all games. Shooting the corners of the screen in gun games whilst in fullscreen mode no longer alters the emulator window or exits by use of the new .ini entry "UseRawInput". When the game fades in or out to and from white, there is no longer a significant performance hit, and the appearance of the transition is now accurate. When selecting the course in Wave Runner, the clouds are no longer red. In Zero Gunner, the audio effect of the boss chopper no longer prematurely sounds during the game. There is no longer a performance drop during certain scenes at the final boss stage in Virtual On Cybertroopers. The BGM volume no longer drops dramatically (almost mute) during a game of Zero Gunner. All analogue controls now function in Wave Runner. The ambience effects (wind/lightening/water etc) now sound during the demo and gameplay in Virtua Fighter 2. The audio in Virtua Cop now supports full FM Synth mode resulting in accurate sound reproduction. In the 2nd lap of the long course in Super GT 24h, there is no longer texture corruption. When setting the country to export in Sky Target with Advertise sound ON, pressing F3 no longer causes the BGM to not play on the first cycle. During the initial entry screen in Sega Touring Car Championship, the BGM now loops instead of terminating prematurely. The sky in some courses in Over Rev are no longer red and display the correct colour. Indy 500 no longer experiences a pause during the "ladies and gentlemen start your engines" screen. There is no longer a performance hit in Fighting Vipers in the Jane stage. There are no longer green artefacts in the facial features in Dead or Alive and Virtua Fighter 2. Daytona USA to the Maxx has now been restored and loads up. White pixels that plagued Daytona USA car rear window bars and race lights have been fixed. There is no longer a performance hit when racing up the hill in Daytona USA advanced course. The music no longer ends abruptly when completing Behind Enemy Lines. The semi-dotted line no longer appears in many games in backdrops like Sega Rally, Dead or Alive, Behind Enemy Lines, Super GT24h, Over Rev and perhaps others. After losing to the final boss in Virtual On Cybertroopers, the explosion no longer disables the BGM.
- 20th October   2008: Model 2 Emulator v0.9 WIP - ElSemi: The way the LOD selection for mipmaps that the model2 hardware performs is still not understood, and it's quite complex, as it requires several conversion tables and parameters that are stored in the display list, polygon header and texture header. I have some clues on how it might work, but it's still not correct and not working yet. If you set AutoMip=1, then the emu tells direct3D to generate all the mipmaps from the highest resolution one. The rest of mipmaps stored in the texture sheets aren't used.The LOD selection is left to D3D internal method, and it causes to switch to lower levels too near from the view point, causing very blurry textures. If you set Trilinear=1, the emu uploads the mipmaps from the texture sheets to D3D textures. There is no (known) indication in the texture header on how many mipmaps the texture sheet contains, so the emu always loads the maximum number (5 LODs). The LOD selection is left to D3D internal method too, so when it chooses to use a LOD that the game didn't upload a mipmap for, it causes black or wrong textures to appear, depending on whether that given texture area is just blank, of it was used to store another texture. In model 2, the part I know works as follows: The display list can upload a table of coefficients to scale the distance (dot product of Vertex0 with normal) of a polygon (let's call this d), this table has 32 different coeffs, let's call them C. It also uploads a table to computes the fractional part of the base 2 logarithm of a given value (it's used for d). There is a command to select a LOD offset. Let's call this L. In the polygon header, it can select one of these 32 scaling coeffs (C) to apply to the distance (d). When sending a poly to the rasterizer, the geometrizer multiplies C by d and by L and sends it along with the transformed vertices and the luminance and front/rear face bit to the rasterizer port. Then little is known on how this value inside the rasterizer selects the LOD level to use, except that it uses the base 2 logarithm of this value. Once I know how to get this value (from 0 to 4) I could sample it from a given lod from the pixel shader (by using tex2dlod, but it will require Pixel Shader 3). Sampling from the given lod, and the next one, and interpolating with the fractional part of the LOD will get a trilinear filtering. Update: I forgot to write that what daytona does in the course selection screen is changing the lod offset (L value) so it forces the hw to select the lower resolution lods as if the polys were very far, so the rasterizer uses the low detail textures, then slowly decreases it so they "come closer" (virtually, as they are at the same view distance), making the HW use the higher resolution textures as they approach.
- 13th October   2008: Model 2 Emulator v0.9 WIP - Peabo: Original model 2 games now display the correct brightness/contrast settings for their cabinet modes. The clouds in Virtua Cop that weren't displaying correctly with the old saturation shader (now completely removed) are working fine now. Another update: Masked texturemaps will no longer have little white pixes around the edges.
-  8th October   2008: Model 2 Emulator v0.9 WIP - Peabo: Virtua Fighter 2 with improved colours: http://www.youtube.com/watch?v=DoVOIPYnYsg&fmt=18. Another game that's looking much better: Virtual On. Viper 2's paint is no longer fading. And a few more: fv1 and sonic1.
-  5th October   2008: Model 2 Emulator v0.9 WIP - Wesker: Rewritten part of video emulation: now more colors show correctly. Added "Indianapolis 500 (Rev A)". Lucisac: One of the most important advancements in 0.9 is the correctly emulated color mixer (2nd last update in the list above) that has just occurred recently. Personally I am really excited about this improvement. Although you will need a Pixel Shader 2.0 card or above to take advantage of the benefits, they include resolution of many clipping issues, accurate color reproduction in all games (except 2 being worked on), which means no more need for the saturation shader (but thanks to the guy who cooked it up) and more. This change also brings a potential performance improvement that may be quite noticeable. ElSemi has rewritten the majority of the rasterizer and texture cache so textures are now cached in the original format (unpacked), meaning less memory usage and a reduction in texture updating that will fix many performance problems like the fade ins and outs of white. There is still work being done to optimize the change in code so stay tuned.
- 14th September 2008: Model 2 Emulator v0.9 WIP - Peabo: I've sent a new 2A board to Elsemi so I suppose he could capture it and check to make sure. No new hair updates yet, no. And subsequently nothing on GTX either as ElSemi is still working on a solution to dump the strange board. He will most certainly figure it out though! The problem is (and I'm paraphrasing here) that there are 2 banks to dump, but both he and I have only been able to dump the first bank. There is an instruction that Daytona GTX would give during the game to tell the board when to switch between banks for whatever reason. The problem is manually sending the board that instruction so that it's possible to read the 2nd bank and make the complete rom. And the emulator will also need a small code adjustment to make this work, although that apparently will be easy.
- 10th September 2008: Model 2 Emulator v0.9 WIP - Lucisac: Thanks to SuperRayman who reported the issue with missing instruments in Virtua Cop 1, they have now been emulated.
-  8th September 2008: Model 2 Emulator v0.9 WIP - Peabo: The Daytona GTX board has arrived and a bit of bad news: The 2A board really is dead. Must have been damaged in transit. I will try and source another one though.
-  6th September 2008: Model 2 Emulator v0.9 WIP - Lucisac: This morning ElSemi has been improving the communication between the main CPU & sound CPU. What was occurring before was the sound stack became full and the last sounds were missed and not executed. One scenario was in Sega Rally Championship, where if you accelerated and stopped too quickly during the countdown, the word "GO" would not sound, and sometimes the BGM would stop. These are ElSemi's words summarised. Peabo: ElSemi is busy working on some other extremely cool things which are equally as amazing as m2emulator, so progress at the moment is slow. But he is very close to being finished with them. It's also important to remember that he had a well deserved holiday recently. The GTX board will arrive next week as well as a proper switched mode PSU so that he can power up the 2A board finally. This does not necessarily mean that any new developments will be made, but it will certainly make things easier as he had to run the 2A game DSP tables on the Daytona board originally. It also means he can see what VF2 is supposed to look like since the game will hopefully boot this time.
- 30th August    2008: Model 2 Emulator v0.9 WIP - Peabo: I suppose people are desperate for new news so here is a small bit: Daytona GTX still needs to be properly dumped. We tried all sorts of stuff to dump the extra board that came with it but to no avail. It has 2 ICs on it as well as some other strange stuff to make them work in conjunction. We can get it to read one bank, but are unable to tell the board to access the 2nd one using the dumping software. ElSemi is building his own interface to read & dump both ICs properly. I will be sending him the GTX stuff when he's completed it.
- 29th July      2008: Model 2 Emulator v0.9 WIP - Peabo: The ambient sounds in VF2 are now working.
- 28th July      2008: Model 2 Emulator v0.9 WIP - Lucisac: After extensive testing of the Model 2 Emulator 0.9 BETA3, I have been able to mark 17 bugs as resolved (BETA2 to BETA3). This is great news, also on top of that some new features are due to be on it's way, once tested as working, you will be the first to know! Hair and props in Fighting Vipers now move (collision problems still under analysis). The audio in House Of The Dead now supports full FM Synth mode. The smoke from the tyres in Over Rev is now correctly aligned. The board check in Rail Chase 2 now functions. The speed of the AI cars in Sega Rally Championship is now correct. The music in Virtua Cop 2 no longer stops when shooting down the Pier St sign. The music in Virtua Cop 2 is no longer delayed during the demo. The placement of the heads in Virtua Fighter 2 is now adjusted correctly. The framerate of Virtua Cop 2 is now correct. The framerate of Virtua Fighter 2 is now correct. 7 games suffering from the 'invalid opcode' error were fixed (hitting F3 to reset a game).
- 27th July      2008: Model 2 Emulator v0.9 WIP - Peabo: ElSemi says: Hair shows now, and gravity works (sort of). but object/body collisions don't work and the hair crosses the body. Update: Hair is working in both VF2 & FV. Sega Rally cars are now running at the correct speed.
- 25th July      2008: Model 2 Emulator v0.9 WIP - Peabo: All games will look bad compared to the original arcade. The monitors they used were specifically designed to ONLY handle the model 2 resolution of medium-res 496x384 so the resulting image would be very smooth.All model 2 games will look blocky since the architecture does not support gourad shading. If you're alluding to the difference in brightness, this cannot have anything to do with the colours since you'll observe the exact same behaviors with colormode 1. This is a geometrizer (lighting) problem. The 'color mixer' even if emulated correctly will not change the way Daytona's colours look as of 0.9. As I have said many times, the colours are correct, there is no ambiguity, they are definitely correct. I have the original arcade which I can look at to make comparison. Any differences you see are due to different lighting. This is apparent from looking at 0.8a where the same problems with darker windscreens can be observed. If it was a colour issue then colormode1 & 2 would exhibit different characteristics in this area. All the games have different methods for handling the colours. That is why VF2, FV and Sonic Fighters all have the same problems whereas Sega Rally & Indy 500 both look great. There is no magic fix for the colour mixer to make everything right. Daytona is completely different from Top Skater. If those problems were related, we'd be seeing pink signs in Daytona too. No approaches have been abandoned. If there is a way to emulate everything perfectly without the use of a 3rd part shader, then that would be great. The thing is that Daytona looks right now so it's been left so that other things can be worked on. That is why we now have VF2 and FV. Once all the annoying bugs have been ironed out, the drive board roms are correctly emulated and a few other little things are fixed, maybe work can be done on perfect colour emulation for all games. Maybe in 1.0 for example. Please try not to worry. I'm not saying that the way Daytona is emulated is the perfect approach, but the end result is the same, and for the moment at least, it is fine. Force feedback is fine the way it is, but ElSemi had to approximate a lot since he didn't know that FFB was handled by a different board. I personally don't have any issues with the vibrating. I'm pretty sure your wheel is meant to vibrate when you start a game on sega rally to simulate the engine effect, but I could be wrong. But regardless, he should now be able to do it more accurately. Previously it was being handled for every game using the same type of signals that Daytona outputs, but in reality each game's drive board has a slightly different rom, so each game will send different signals to the motor. You probably won't even notice the difference, but it's one step closer to perfect emulation.
- 24th July      2008: Model 2 Emulator v0.9 WIP - Peabo: ElSemi is working on getting the hair and other elements working in VF2 and FV.
- 23rd July      2008: Model 2 Emulator v0.9 WIP - Peabo: The disappearing player models bug in VF2 is definitely fixed now, so the game is playable. The characters just have no hair sometimes.
- 22nd July      2008: Model 2 Emulator v0.9 WIP - Peabo: ElSemi narrowed the hairs gravity problem down to an i960 bug since Fighting Vipers also has no hair though it uses a totally different DSP program. It's also the i960 that's causing the slow opponents in Sega Rally.
- 21st July      2008: Model 2 Emulator v0.9 WIP - Peabo: Guru may have a bit of trouble redumping VCop 2 because he doesn't have the boards handy and would have to go to where the cabinet is located or get the cabinet sent to him to do it. I will try to borrow the EPROMs that were bad and redump them myself in the meantime, and also try and redump that bad Manx TT sound rom (I'm sure you're tired of hearing a Japanese lady every time you skid). Update: Guru was able to find some VCop 2 roms, so it's been redumped. Hopefully it's a good dump!
- 20th July      2008: Model 2 Emulator v0.9 WIP - Peabo: Vcop 2 is a bad dump apparently! Guru will need to redump it. Vcop works fine, but the rom is bad so some polygons are missing. VF2 has upside-down characters at the moment, but that's being worked on. Update: Fixed upside down fighters. Update2: VF2 still has colour problems very similar to what Daytona used to. The same goes for Fighting Vipers, Sonic Fighters (same engine) and a few others.
- 19th July      2008: Model 2 Emulator v0.9 WIP - Peabo: VF2 isn't working yet. The 2A board still hasn't been powered up properly due to issues with the PSU. But for now ElSemi is running some of the 2A chips on the Daytona rom board. He has already seen differences in the DSP output. Progress is being made.
- 18th July      2008: Model 2 Emulator v0.9 WIP - Peabo: I've ordered Daytona GTX which will be dumped and added to 0.9.
- 13th July      2008: Model 2 Emulator v0.9 WIP - Peabo: Fixed Daytona colours.
- 12th July      2008: Model 2 Emulator v0.9 WIP - Peabo: The version of VF2 I sent is apparently the original version (revision A). The current dumped ones were rev B and 2.1. Also the dump of Daytona Deluxe '93 was successful too. Update: ElSemi is having a few problems getting the VF2 board to boot, but I'm sure it's because he's using a regular PC power supply. Those things need a decent amount of voltage to get them running. I know I can make Daytona crash if I turn the voltage down on my PSU. There are no error LEDs on the board when it turns on so hopefully it's fine.
-  1st July      2008: Model 2 Emulator v0.9 WIP - Peabo: The colours are almost perfect now. There are a few problems with the dark greens, blues & grays (the grass, tires and sky reflection are the most prominent examples of this), but they can certainly be fixed as they were fine when ElSemi originally tired this method to fix the colours in early versions of 0.5. It must have been something else that was changed between 0.5 and 0.8 that makes them so dark in the new screenshots. Unfortunately ElSemi forgot exactly what he changed! Luckily I can run the boards to look at the actual colours for reference. ElSemi's ones run a bit too bright on his monitor, unfortunately. It's probable that they will be perfect (at least in Daytona) in 0.9. By the way, there is a new feature in 0.9: meshed textures that are resolution dependent. So you will still see them if you run Daytona at a high res. On a side note, I've sent 2 EEPROMs to ElSemi which should enable him to look at the DSP tables on VF2 and VCop2 (using the Daytona board) in order to hopefully get those games functioning. They should be with him in a day or two.
- 28th June      2008: Model 2 Emulator v0.9 WIP - Added an option to regulate the Gamma values of the RGB (separately). Eliminated the errors related to invisible walls in Daytona the USA. Fixed a problem in the sound of Model 2, that caused loops in some samples.
- 24th June      2008: ElSemi - Model 2 emulator 0.8a: Fixed missing trigger buttons in gun games. Fixed Desert Tank locked into test mode. Improved main cpu/sound CPU sync in Model2 Original games.
- 23rd June      2008: ElSemi - Model 2 emulator 0.8: Rewritten the MultiPCM sound chip emulation. It fixes Original Model2 games sounds and music. Fixed eye paremeters being read as unsigned by the display list parser, causing bad geometry in daytona 4 players attract and sega rally 2 players attract.  Fixed network board detection for sgt24h and overrev. Now you don't need to enable network to have them boot. Adjusted daytona steering limits to the real machine limits (according to the service manual). It should have a more accurate handling now. Added force feedback for car driving games. You need to enable it in the .ini using the option EnableFF=1 in the Input section. You can tweak more force parameters in that section. Also some games only enable the force feedback if the cabinet type is set to Deluxe in the test mode. Added XInput support. You can enable XInput support in the .ini in the Input section. XInput allows direct access to XBox360 compatible controllers for vibration (they don't support vibration through DirectInput). Keep in mind that the windows XInput libraries only support vibration force feedback so an XBox360 driving controller won't have working force effects.  Added optional meshed polygons for translucency (like the hardware does). Enable it with MeshTransparency=1 in the ini. This option requires a Pixel Shader 3 capable videocard. Fixed HOTD rom loading that caused missing tilemap graphics (how to play, map on gameover). Added preliminary savestates support. The sound engine state is not being saved yet. I've added this so I can ask for states to try to fix the invisible walls problem in daytona.
-  4th June      2008: ElSemi - Model 2 emulator 0.7a: Fixed network code not fully working (I accidentally left a part disabled in the last build). Improved daytona video & sound sync.
-  3rd June      2008: ElSemi - Model 2 emulator 0.7: More accurate emulation of some TGP by using the data tables from the mainboard. You'll need these table roms in Model2.zip or inside the game zip. Thanks to Peabo for the donation of a Daytona board that helped to understand how they worked. This has fixed most of the bugs in daytona usa (reverse and most invisble wall hits) and sega rally (automatic transmission). Improved color table decoding that gives more bright colors for some games. Improved SCSP timing. It should be more accurate and musics should not sound out of sync anymore. As a bonus feature i've left in a debug sound player that allows you to load a SSF (Saturn Sound Format) file for playing. To use it, load a game using SCSP (model 2a,b or c) and enter test mode (so it doesn't send sound commands) then press LeftControl+F5 and choose the ssf file to play. Improved clipping. By moving to vertex/pixel shaders i've got rid of all the clipping issues that happened with ATI video cards and recent NVIDIA ones. Remember to remove set SoftwareVertexProcessing to 0. You'll need a pixel shader 1.1 and vertex shader 1.1 capable card. It's the lowest shader version so any video should work. As a side effect of this change, there is only a geometrizer now, so the Geometrizer opion in the ini file is not used. Fixed problems with textures ending in the lowest line of the texture sheet not being uploaded to direct3d (Sega Rally black background in 2nd stage and Topskater missing floors). Added Wave Runner (Model 2C). Added support for direct3d automimpap generation (see emulator.ini AutoMip option). Added network emulation.
-  3rd January   2008: ElSemi - Model 2 emulator 0.6: So many changes that I can't remember. Lighting fixes, control fixes and sound fixes. ManxTT is working, but sound is broken. Merged some features from the CPS3 emu (vsync, custom fullscreen res,...).
- 29th May       2007: ElSemi - Model 2 emulator 0.5a: Fixed (hopefully at last) the analog wraparound bug. Fixed wrong colour table translation in vcop madium and expert levels. Added a couple of useful features: Launch game from commandline (just add the driver name. ex: Emulator.exe stcc) and Auto-switch to fullscreen after game loading (the option is in the Video menu).
- 24th May       2007: ElSemi - Model 2 emulator 0.5: This release fixes several playability bugs in Daytona USA (analog controls wraparound and windows disappearing when going to fullscreen) and adds a new playable game: Motor Raid. It also contains a modified color lookup table processing that improves the colors in the original model 2 games (daytona, vcop and dtank). The emulator now includes a nice icon and background image, thanks to jordigahan and Peabo for them.
-  3rd April     2007: ElSemi - Model 2 emulator 0.4: The Model 2 Emulator supporting some Model 2 and Model 2 A-CRX boards (Daytona anyone? ). This version of the emulator includes a preliminary emulation of the Fujitsu MB86234 DSP present in these boards. Keep in mind that the emulation is still preliminary, as there is no documentation on this chip, and it has been done by reverse engineering the binary programs and comparing with the model 2B and 2C programs and the MAME Model 1 HLE. I'd like to thank Olivier Galibert and Ernesto Corvi for their help in making possible this DSP emulation. Check the include README.TXT for instructions (especially how to set Daytona to Standalone machine as Multiplayer is not implemented) and known emulation bugs in the games.
- 11th February  2007: ElSemi - Model 2 emulator 0.3 MultiCPU Experimental: This is an experimental Model 2 emulator build using multithreaded code for parallel CPU, GPU and Sound emulation. It's designed to have a huge performance boost in Multi-Core CPUs (Dual Core and Core Duo) as it will allow the emulator to use both cores in parallel. As a bonus, this emulator contains an experimental recompiler SCSP DSP emulation.
- 22nd August    2006: ElSemi - Model 2 emulator 0.3: After more than 2 years without updates here is a new version of my Model 2 Emulator. The main changes are all speed related. The emu should be faster now. Also it now supports Frameskip and AutoFrameskip. This will probably be the last version of the emulator unless some Fujitsu TGP MB86234 docs appear to finish the emulation of the 2 and 2A cores.
- 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  M48T35
  8.32  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        (TMS27128J, 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 is 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)
82S136 = 1024 bytes  (?)
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.130u3            : Added machine\eepromdev.c/h. Samuele Zannoli added device-based implementations of the EEPROM and i2c devices.
- 0.129u6            : Pierpaolo Prazzoli changed EEPROM erase command to write 0xff values. 
- 0.129              : smf fixed AT28C16 so that a write isn't allowed to start if there is one in progress and a write isn't started if the data is already correct. This allows my dream horse to boot again. Further investigation is needed.
- 0.127              : smf changed AT28C16 memory handlers to 8 bits and perform the conversion in the memory mapping.
- 0.126u1            : Aaron Giles changed direct access EEPROM interface to return the "bus width" of the EEPROM data, and the size is in terms of units, not bytes. Updated all drivers accordingly.
- 0.125u3            : Aaron Giles renamed EEPROM_* to eeprom_*. Updated all drivers accordingly. Typedef'ed a real eeprom_interface structure.
- 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.
- 0.35RC1            : Added machine\eeprom.c/h.
- 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

-  1st June      2008: Charles MacDonald - Last year I designed a 16-bit EPROM emulator based around the IDT7025 8Kx16 dual-port static RAM, a very useful chip that supports 8 and 16-bit access independently on either of its RAM ports. This is what I used for running tests on my Model 1 and Jaleco Mega System 32 boards, the latter needing two emulators in parallel to emulate four EPROMs. The software to control it was a modified version of the 8-bit EPROM emulator utility. Support for multiple devices isn't implemented quite right, so just use it for controlling a single device. This ended up being my first project that used almost all surface mount parts, as well as PLCC chips. I'm quite proud of the way it came out, and so far it has been invaluable for running tests on 16-bit and 32-bit systems. Here is the PCB layout, documentation, utility program and source code: http://cgfm2.emuviews.com/zip/ds-060108.zip. At some point I was thinking of making adapter PCBs that would support 27C4096 and 27C400 type pinouts as I have a few boards with those chips instead of two 8-bit EPROMs in parallel. It's just a wiring difference but this would be a neater solution and simplify cable assembly.
-  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
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)
CXK58256        32k x 8  SRAM                    58256                          (NeoGeo)
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.131              : Aaron Giles changed generic NVRAM behavior so that all the variants look for a memory region named "nvram". If it is found and is of the same length as the generic_nvram_size, data is copied from there instead of filling the RAM with the fallback pattern.
- 0.130              : Aaron Giles added muting just before saving the NVRAM, and de-mute just after loading the NVRAM. Should cure the stuck sound issue for games with large NVRAM.
- 0.128u7            : Aaron Giles changed various NVRAM devices to fetch their default memory region from the device->region rather than specifying it in the configuration.
- 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.3   X2212
- 0.127u4: Added machine\x2212.c/h.
- NOTES: Xicor X2212 Nonvolatile Static RAM (256 x 4 bit)

R4.3   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  M48T35
- 0.127: smf identified compatible timekeeper used by Midway Zeus II. Removed all the timekeeper memory handlers, except for 8 bit & changed the drivers to use the conversion built into the memory system.
- DRIVERS: midzeus.c

R8.32  M48T58
- 0.127u2            : smf converted timekeeper to a device, all default contents are loaded from disk.
- 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
BPP    = Bits Per Plane
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
eSATA  = external Serial ATA
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 Processing 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
PCIe   = Peripheral Component Interconnect Express
PCM    = Pulse Code Modulation
PCMCIA = Personal Computer Memory Card International Association
PWM    = Pulse Width Modulation
PPCM   = Packed PCM
PIA    = Peripheral Interface Adapter
PIC    = Programmable Interrupt Controller
PIO    = Parallel Input Output
PIT    = Programmable Interval Timer
PLD    = Programmable Logic Device
PPI    = Programmable 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
VPU    = Visual Processing Unit
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


CRC32  = Cyclic Redundancy Code
MD5    = Message Digest number 5
SHA-1  = Secure Hash Algorithm


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
UMC         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
SNK    = Shin Nihon Kikaku
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
6262: Cairblad
6269: Lstfort
6508 = 6502 ?: Astrof
70337: Firebarr
71AJC46A (SOIC8): Harley, Sega-Model3
75365: Buckrog
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
CF37201: IDsoccer
CA810AQM (sound Amplifier?): Invaders
D31B3100: Murogem
D481165 = D4811650GF: Harley
D482445 = D482445LGW-A70 = DRAM?: Btchamp, Sidebs/2, KonamiGVSystem
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
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
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
NB19010 and NB22090: Mahjong games
NTA0002 (QFP80): Chameleon 24-in-1
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
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



FOUND
-----
75LBC176: Radikalb, Surfplnt = Differential Bus Transceivers
DAC76: Beezer = DAC7611 = 12-Bit Serial Input DAC 
M24CL16-S: Bballoon = 16Kb FRAM Serial 3V Memory
MAB8031AH: Chelnov = Philips MAB8031AH/8051AH MCU = Single-chip 8-bit microcontroller 
---------------------------------------------------------------------------------------------------------------------



Links:
------
CHIP SEARCH: http://www.xs4all.nl/~ganswijk/chipdir/
http://www.datasheetcatalog.net/
http://category.alldatasheet.com/
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.elektronik-kompendium.de/


Hardware:
www.andysarcade.net/

Manuals:
http://pdf.textfiles.com/manuals/ARCADE/SMALLFILENAME/
http://www.crazykong.com/manuals/
http://www.cityofberwyn.com/manuals/index.htm
http://www.vernimark.com/arcade/

Dipswitch 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-2009  M.A.S.H.

