NeoGeo Development Wiki - User contributions [en]

NEO-ZMC2

2026-08-18T03:59:04Z

Furrtek: /* Pinout */

{{ChipInfo
|picture=mvs_zmc2.jpg
|pkg=QFP80R
|manu=fujitsu
|date=1990
|gates=
|used_on={{PCB|MV1FZS}} [[Cartridges]]...
}}

{{Chipname|NEO-ZMC}} and {{Chipname|PRO-CT0}} in one package.

Can address up to 4MiB of [[M1 ROM]].

Found in second revision [[MVS hardware|MVS]] boards (for the PRO-CT0 logic only), and AES cartridges.

=Pinout=

{{Pinout|NEO-ZMC2|640px}}

NEO-ZMC part:
*SDA0,SDA1,SDA8~SDA15: [[Z80]] address bus
*MA11~MA21: M ROM address outputs

Serializer part, inputs:
*12M: 12MHz clock, outputs next pixel on falling edge.
*C0~C31: C ROM data bus (2*16 bits). Gives all the pixel data needed for a 8 pixel line.
*H: When high, reverse bit order of pixels shifted out (used for [[sprites]] horizontal flipping)
*EVEN: Swap A/B pixel outputs
*LOAD: Latch C ROM data on falling edge of 12M
*CSDOT: Active low DOTA/DOTB output enable
*CS: Active low GADx/GBDx output enable
Outputs:
*DOTA: High when pixel A is opaque (color > 0)
*DOTB: High when pixel B is opaque (color > 0)
*GAD0~GAD3: Pixel A color index
*GBD0~GBD3: Pixel B color index

=Signals=

[[File:Spr signals.png]]

[[Category:Chips]]

Clock

2026-08-17T20:09:58Z

Furrtek: /* In cartridge systems */

Not to be confused with the [[RTC|real time clock]] (RTC), which is a time-keeping system used in the [[MVS]] and clocked independently from the rest of the system.

[[File:Clkdistribution.png|frame]]

=In cartridge systems=

The main system clock (often called '''mclk''') is either 24MHz (MVS) or 24.167829MHz (AES). It is generated from a crystal oscillator and divided down by {{Chipname|NEO-D0}} (or other later chips), to provide the 12MHz clock for {{Chipname|NEO-ZMC2}}, the 6MHz pixel clock for [[video DAC|video output]] and many others.

{{Chipname|LSPC2-A2}} (or other later chips) divides it by 3 and 6 to provide the 8MHz clock for the {{Chipname|YM2610}} and the 4MHz one for the {{Chipname|Z80}}.

The cartridge connector provides the 24MHz, 12MHz, 8MHz and 4MHz inverted clock signals.

A second quartz oscillator is used in the AES for generating the color burst needed by composite video, for the [[video encoder]]s.

The value changes depending on the region of the system, 4.43361875Mhz for PAL systems and 3.579545Mhz for NTSC systems.

A third 32.768KHz quartz oscillator is present in the MVS used for the [[RTC|real time clock]].

[[File:clock.png]]

==Phase relations==

To do: 8M is 33high/66low, not 50/50

[[File:Clockphases.png]]

==Signals==

{{Sig|24M|24M}} (~24MHz), {{Sig|12M|12M}} (12MHz), {{Sig|68KCLK|68KCLK}} (12MHz), {{Sig|68KCLKB|68KCLKB}} (12MHz), {{Sig|8M|8M}} (8MHz), {{Sig|6MB|6MB}} (6MHz), {{Sig|4M|4M}} (12MHz), {{Sig|4MB|4MB}} (4MHz), {{Sig|1MB|1MB}} ('''3MHz''')

=In CD systems=

[[File:Cd2_quartz.jpg|thumb|System clock and [[video PLL]] circuit on a CDM3-2 board.]]

{{Chipname|NEO-GRC}} ?

[[Category:Base system]]

Clock

2026-08-17T20:07:07Z

Furrtek:

Not to be confused with the [[RTC|real time clock]] (RTC), which is a time-keeping system used in the [[MVS]] and clocked independently from the rest of the system.

[[File:Clkdistribution.png|frame]]

=In cartridge systems=

The main system clock (often called '''mclk''') is either 24MHz (MVS) or 24.167829MHz (AES). It is generated and divided by 2, 4 and 8 by {{Chipname|NEO-D0}} from a crystal oscillator, to provide the 12MHz clock for {{Chipname|NEO-ZMC2}}, the inverted 6MHz one for [[video DAC|video output]] and also the 3MHz one for {{Chipname|NEO-B1}}.

{{Chipname|LSPC2-A2}} divides it by 3 and 6 to provide the 8MHz clock for the {{Chipname|YM2610}} and the 4MHz one for the {{Chipname|Z80}}.

The cartridge connector provides the 24MHz, 12MHz, 8MHz and 4MHz inverted clock signals.

A second quartz oscillator is used in the AES for generating the color burst needed by composite video, for the [[video encoder]]s.

The value changes depending on the region of the system, 4.43361875Mhz for PAL systems and 3.579545Mhz for NTSC systems.

A third 32.768KHz quartz oscillator is present in the MVS used for the [[RTC|real time clock]].

[[File:clock.png]]

==Phase relations==

To do: 8M is 33high/66low, not 50/50

[[File:Clockphases.png]]

==Signals==

{{Sig|24M|24M}} (~24MHz), {{Sig|12M|12M}} (12MHz), {{Sig|68KCLK|68KCLK}} (12MHz), {{Sig|68KCLKB|68KCLKB}} (12MHz), {{Sig|8M|8M}} (8MHz), {{Sig|6MB|6MB}} (6MHz), {{Sig|4M|4M}} (12MHz), {{Sig|4MB|4MB}} (4MHz), {{Sig|1MB|1MB}} ('''3MHz''')

=In CD systems=

[[File:Cd2_quartz.jpg|thumb|System clock and [[video PLL]] circuit on a CDM3-2 board.]]

{{Chipname|NEO-GRC}} ?

[[Category:Base system]]

NEO-PCM2

2026-08-16T19:01:10Z

Furrtek:

{{ChipInfo
|picture=brd_pcm2.jpg
|pkg=QFP120
|manu=fujitsu
|date=2001 ?
|gates=
|used_on=[[Cartridges]], [[ROM-Only boards]]
}}

Second version of {{Chipname|PCM}}. [[V ROM]] (de)multiplexer, decryption and [[P ROM]] banking chip.

The decryption algorithm used by emulators may not be perfectly exact, this could be a possible cause of incorrect data in decrypted romsets causing minor audio glitches (Samurai Shodown V "Basara").

Used by:

* [[Matrimelee]]
* [[Metal Slug 4]]
* [[Metal Slug 5]]
* [[Pochi and Nyaa]]
* [[Rage of the Dragons]]
* [[Samurai Shodown V]]
* [[Samurai Shodown V Special]]
* [[SNK vs. Capcom - SVC Chaos]]
* [[The King of Fighters 2001]]
* [[The King of Fighters 2002]]
* [[The King of Fighters 2003]]

=Pinout=

[[File:Neo-pcm2_pinout.png|800px]]

OpenOffice Draw file: [[File:neo-pcm2.odg]]

[[Category:Chips]]

NEO-244

2026-08-15T23:59:55Z

Furrtek:

{{ChipInfo
|picture=Neo-244.jpg
|pkg=QFP64R
|manu=fujitsu
|date=1992 ?
|gates=
|used_on={{PCB|SLOT4F}}
}}

Just a bunch of buffers for second revision 4-slot MVS boards. 18 inputs to 2 x 18 always enabled outputs. See MV4F schematics.

=Pinouts=

==Generic==

{{Pinout|NEO-244|640}}

==SLOT4F==

<gallery>
File:NEO-244_mv4f_a1_pinout.png|A1: Buffers for 68k address lines
File:NEO-244_mv4f_a2_pinout.png|A2: Buffers for control lines
File:NEO-244_mv4ft_b2_pinout.png|B2: Buffers for Z80 address lines
File:NEO-244_mv4ft_c2_pinout.png|C2: Buffers for P bus lines
File:NEO-244_mv4ft_d2_pinout.png|D2: Buffers for P bus and other lines
File:NEO-244_mv4ft_e2_pinout.png|E2: Buffers for ADPCM lines
</gallery>

[[Category:Chips]]

NEO-244

2026-08-15T23:59:39Z

Furrtek: /* Pinouts */

{{ChipInfo
|picture=Neo-244.jpg
|pkg=QFP64R
|manu=fujitsu
|date=1992 ?
|gates=
|used_on={{PCB|SLOT4F}}
}}

Just a bunch of buffers for second revision 4-slot MVS boards.

=Pinouts=

==Generic==

{{Pinout|NEO-244|640}}

==SLOT4F==

<gallery>
File:NEO-244_mv4f_a1_pinout.png|A1: Buffers for 68k address lines
File:NEO-244_mv4f_a2_pinout.png|A2: Buffers for control lines
File:NEO-244_mv4ft_b2_pinout.png|B2: Buffers for Z80 address lines
File:NEO-244_mv4ft_c2_pinout.png|C2: Buffers for P bus lines
File:NEO-244_mv4ft_d2_pinout.png|D2: Buffers for P bus and other lines
File:NEO-244_mv4ft_e2_pinout.png|E2: Buffers for ADPCM lines
</gallery>

[[Category:Chips]]

File:NEO-244 pinout.png

2026-08-15T23:58:48Z

Furrtek: Furrtek uploaded a new version of File:NEO-244 pinout.png

NEO-253

2026-08-15T23:58:11Z

Furrtek: /* Pinout */

{{ChipInfo
|picture=Neo-253.jpg
|pkg=QFP64R
|manu=fujitsu
|date=1992 ?
|gates=
|used_on={{PCB|SLOT4F}}
}}

Quintuple 74HC253 4-to-1 multiplexers with common select lines, making ten 4-to-1 switches in one chip. Used to switch read-only buses. The inputs are named according to the related slot: A is slot #1, B is slot #2...

Only (?) used on second revision 4-slot MVS systems. Not to be confused with the more common {{Chipname|NEO-273}}.

=Pinout=

[[File:Neo-253_pinout.png|512px]]

Select signals come from {{Chipname|NEO-F0}} SLOTA and SLOTB.

==SLOT4F @ 5E==

Cartridge [[wait cycle]] configuration and [[Z80]] bus.

*Mux 1: PWAIT0
*Mux 2: PWAIT1
*Mux 10~3: SDD7~SDD0

Outputs go to CN9.

==SLOT4F @ 5D==

[[Sprites]] and [[fix layer]] graphics.

*Mux 1: CR30
*Mux 2: CR31
*Mux 10~3: FIXD7~FIXD0

==SLOT4F @ 5C==

Sprite graphics.

*Mux 10~1: CR29~CR20

==SLOT4F @ 5B==

Sprite graphics.

*Mux 10~1: CR19~CR10

==SLOT4F @ 5A==

Sprite graphics.

*Mux 10~1: CR9~CR0

[[Category:Chips]]

File:Neo-253 pinout.png

2026-08-15T23:57:20Z

Furrtek: Furrtek uploaded a new version of File:Neo-253 pinout.png

NEO-244

2026-08-15T23:37:21Z

Furrtek: /* Pinouts */

{{ChipInfo
|picture=Neo-244.jpg
|pkg=QFP64R
|manu=fujitsu
|date=1992 ?
|gates=
|used_on={{PCB|SLOT4F}}
}}

Just a bunch of buffers for second revision 4-slot MVS boards.

=Pinouts=

To fix on diagram:
Pin 18 input, output 15, 21.
Pin 50 not an /OE, regular input, output 47, 53. Never used on any board ?
Outputs are always enabled. See MV4F schematics. Simple 18 inputs to 2x18 outputs.

==Generic==

{{Pinout|NEO-244|640}}

==SLOT4F==

<gallery>
File:NEO-244_mv4f_a1_pinout.png|A1: Buffers for 68k address lines
File:NEO-244_mv4f_a2_pinout.png|A2: Buffers for control lines
File:NEO-244_mv4ft_b2_pinout.png|B2: Buffers for Z80 address lines
File:NEO-244_mv4ft_c2_pinout.png|C2: Buffers for P bus lines
File:NEO-244_mv4ft_d2_pinout.png|D2: Buffers for P bus and other lines
File:NEO-244_mv4ft_e2_pinout.png|E2: Buffers for ADPCM lines
</gallery>

[[Category:Chips]]

NEO-253

2026-08-15T23:31:20Z

Furrtek: /* Pinout */

{{ChipInfo
|picture=Neo-253.jpg
|pkg=QFP64R
|manu=fujitsu
|date=1992 ?
|gates=
|used_on={{PCB|SLOT4F}}
}}

Quintuple 74HC253 4-to-1 multiplexers with common select lines, making ten 4-to-1 switches in one chip. Used to switch read-only buses. The inputs are named according to the related slot: A is slot #1, B is slot #2...

Only (?) used on second revision 4-slot MVS systems. Not to be confused with the more common {{Chipname|NEO-273}}.

=Pinout=

[[File:Neo-253_pinout.png|512px]]

OpenOffice Draw file: [[File:neo-253.odg]]

Pin 56 is a general /OE.

Select signals come from {{Chipname|NEO-F0}} SLOTA and SLOTB.

==SLOT4F @ 5E==

Cartridge [[wait cycle]] configuration and [[Z80]] bus.

*Mux 1: PWAIT0
*Mux 2: PWAIT1
*Mux 10~3: SDD7~SDD0

Outputs go to CN9.

==SLOT4F @ 5D==

[[Sprites]] and [[fix layer]] graphics.

*Mux 1: CR30
*Mux 2: CR31
*Mux 10~3: FIXD7~FIXD0

==SLOT4F @ 5C==

Sprite graphics.

*Mux 10~1: CR29~CR20

==SLOT4F @ 5B==

Sprite graphics.

*Mux 10~1: CR19~CR10

==SLOT4F @ 5A==

Sprite graphics.

*Mux 10~1: CR9~CR0

[[Category:Chips]]

Wait cycle

2026-08-15T17:49:34Z

Furrtek: /* Cartridge configuration */

The [[68k]] is able to wait for data by using wait cycles during bus access. This allows the use of slow, cheaper memories in cartridges and memory cards.

The NeoGeo has wait state generation for 3 [[68k memory map|memory zones]]:

* 000000~0FFFFF: ROM zone ([[P ROM]]) - Configurable, 0 or 1 cycle
* 200000~2FFFFF: PORT zone ([[P ROM]] or special chips) - Configurable, 0, 1, 2 or more cycles
* 800000~BFFFFF: [[Memory card]] - Fixed, 2 cycles

=Cartridge configuration=

Configuration is done by setting the levels of the following [[pinouts|cartridge pins]]. '1' means pulled to 5V, '0' means pulled to ground. All signals are active low.

Many cartridges have all these pins tied to 5V to select full speed for both memory areas.

{|class="wikitable"
!ROMWAIT||ROM zone wait
|-
|1||Full speed
|-
|0||1 cycle
|}

{|class="wikitable"
!PWAIT1||PWAIT0||PORT zone wait
|-
|1||1||Full speed
|-
|1||0||1 cycle
|-
|0||1||2 cycles
|-
|0||0||As long as PDTACK is high
|}

=Use cases=

Some games rely on wait cycles to perform sufficiently spaced [[VRAM]] accesses. Disabling the wait on those cartridges causes the accesses to become too close to each other and results in graphics corruption.

No originally released cartridges are known to use PDTACK.

[[Category:Base system]]

Template:BR

2026-08-15T14:51:11Z

Furrtek:

'''[[BIOS_RAM_locations#{{{1}}}|{{{1}}}]]''' ({{ #ifeq: {{{1|}}} | BIOS_GAME_DIP | $10FD84+}}{{ #ifeq: {{{1|}}} | BIOS_USER_REQUEST | $10FDAE}}{{ #ifeq: {{{1|}}} | BIOS_USER_MODE | $10FDAF}}{{ #ifeq: {{{1|}}} | BIOS_UPSRC | $10FEF8}}{{ #ifeq: {{{1|}}} | BIOS_UPDEST | $10FEF4}}{{ #ifeq: {{{1|}}} | BIOS_UPSIZE | $10FEFC}}{{ #ifeq: {{{1|}}} | BIOS_UPZONE | $10FEDA}}{{ #ifeq: {{{1|}}} | BIOS_UPBANK | $10FEDB}}{{ #ifeq: {{{1|}}} | BIOS_DEVMODE | $10FE80}}{{ #ifeq: {{{1|}}} | BIOS_COMPULSION_TIMER | $10FDDA}}{{ #ifeq: {{{1|}}} | BIOS_GAME_DIP | $10FD84}}{{ #ifeq: {{{1|}}} | BIOS_CREDIT_DEC1 | $10FDB0}}{{ #ifeq: {{{1|}}} | BIOS_CREDIT_DEC2 | $10FDB1}}{{ #ifeq: {{{1|}}} | BIOS_START_FLAG | $10FDB4}}{{ #ifeq: {{{1|}}} | BIOS_PLAYER_MOD | $10FDB6}}{{ #ifeq: {{{1|}}} | BIOS_P1STATUS | $10FD94}}{{ #ifeq: {{{1|}}} | BIOS_MONTH | $10FDD3}}{{ #ifeq: {{{1|}}} | BIOS_MVS_FLAG | $10FD82}})

Template:BR

2026-08-15T14:50:49Z

Furrtek:

'''[[BIOS_RAM_locations#{{{1}}}|{{{1}}}]]''' ({{ #ifeq: {{{1|}}} | BIOS_GAME_DIP | $10FD84+}}{{ #ifeq: {{{1|}}} | BIOS_USER_REQUEST | $10FDAE}}{{ #ifeq: {{{1|}}} | BIOS_USER_MODE | $10FDAF}}{{ #ifeq: {{{1|}}} | BIOS_UPSRC | $10FEF8}}{{ #ifeq: {{{1|}}} | BIOS_UPDEST | $10FEF4}}{{ #ifeq: {{{1|}}} | BIOS_UPSIZE | $10FEFC}}{{ #ifeq: {{{1|}}} | BIOS_UPZONE | $10FEDA}}{{ #ifeq: {{{1|}}} | BIOS_UPBANK | $10FEDB}}{{ #ifeq: {{{1|}}} | BIOS_DEVMODE | $10FE80}}{{ #ifeq: {{{1|}}} | BIOS_COMPULSION_TIMER | $10FDDA}}
{{ #ifeq: {{{1|}}} | BIOS_GAME_DIP | $10FD84}}{{ #ifeq: {{{1|}}} | BIOS_CREDIT_DEC1 | $10FDB0}}{{ #ifeq: {{{1|}}} | BIOS_CREDIT_DEC2 | $10FDB1}}{{ #ifeq: {{{1|}}} | BIOS_START_FLAG | $10FDB4}}{{ #ifeq: {{{1|}}} | BIOS_PLAYER_MOD | $10FDB6}}{{ #ifeq: {{{1|}}} | BIOS_P1STATUS | $10FD94}}{{ #ifeq: {{{1|}}} | BIOS_MONTH | $10FDD3}}{{ #ifeq: {{{1|}}} | BIOS_MVS_FLAG | $10FD82}})

Template:BR

2026-08-15T14:50:20Z

Furrtek:

'''[[BIOS_RAM_locations#{{{1}}}|{{{1}}}]] '''
({{ #ifeq: {{{1|}}} | BIOS_GAME_DIP | $10FD84+}}{{ #ifeq: {{{1|}}} | BIOS_USER_REQUEST | $10FDAE}}{{ #ifeq: {{{1|}}} | BIOS_USER_MODE | $10FDAF}}{{ #ifeq: {{{1|}}} | BIOS_UPSRC | $10FEF8}}{{ #ifeq: {{{1|}}} | BIOS_UPDEST | $10FEF4}}{{ #ifeq: {{{1|}}} | BIOS_UPSIZE | $10FEFC}}{{ #ifeq: {{{1|}}} | BIOS_UPZONE | $10FEDA}}{{ #ifeq: {{{1|}}} | BIOS_UPBANK | $10FEDB}}{{ #ifeq: {{{1|}}} | BIOS_DEVMODE | $10FE80}}{{ #ifeq: {{{1|}}} | BIOS_COMPULSION_TIMER | $10FDDA}}
{{ #ifeq: {{{1|}}} | BIOS_GAME_DIP | $10FD84}}{{ #ifeq: {{{1|}}} | BIOS_CREDIT_DEC1 | $10FDB0}}{{ #ifeq: {{{1|}}} | BIOS_CREDIT_DEC2 | $10FDB1}}{{ #ifeq: {{{1|}}} | BIOS_START_FLAG | $10FDB4}}{{ #ifeq: {{{1|}}} | BIOS_PLAYER_MOD | $10FDB6}}{{ #ifeq: {{{1|}}} | BIOS_P1STATUS | $10FD94}}{{ #ifeq: {{{1|}}} | BIOS_MONTH | $10FDD3}}{{ #ifeq: {{{1|}}} | BIOS_MVS_FLAG | $10FD82}})

Slot check security

2026-08-15T14:47:32Z

Furrtek:

[[File:S3warning.png|frame|Warning screen as shown by [[Sengoku 3]] when booting on MVS hardware with BIOS_MVS_FLAG set to 0 (AES mode).]]

Slot checking is a MVS security measure added in some games produced after 1998 due to the emergence of [[bootleg MVS boards]]. It displays a warning screen and locks the game up if some checks fail.

Someone who would want to bypass this check would typically search for the warning text string in the [[P ROM]] and references to it in the code. Such text can't be found because the checking routine uses a XORed version of it instead, to confuse hackers.

=KOF 98=

If the game figures out it is being run for the first time on the system (thanks to [[backup RAM]] data), it tries to trigger a [[watchdog]] reset. If the system continues running instead due to the absence of the watchdog circuit, the game displays the warning screen and locks up.

=Other games=

*The calendar data zone in the [[BIOS RAM locations|BIOS RAM]] is cleared, then [[READ_CALENDAR]] is called. If {{BR|BIOS_MONTH}} is greater than 13 (should be 12 ? Is that a bug ?), the check fails. This causes bootleg boards with no [[RTC]] to trigger the security.
*If {{BR|BIOS_MVS_FLAG}} is zero (BIOS in AES mode), and bit 7 of {{Reg|REG_STATUS_B}} is set (MVS hardware), the check fails. This causes bootleg boards using a copy of the AES system ROM or those that don't handle REG_STATUS_B reads to trigger the security.

Depending on the result of those checks, the value $8B55 (pass) or $9DBD (fail) is written to [[VRAM]] at $7FFF. This furthermore verifies that the board has full VRAM.

That VRAM value is then read back and added to $74AB (=$10000 if checks passed) to set the byte at $10FCEF (fail) or not.

A later version of this procedure also times the Z80 reply to command $01. $10FCEE = $FF if Z80 was too slow.

Todo: Add more details.

==Use by games==

As seen in MAME's source ([[https://github.com/mamedev/mame/blob/master/src/mame/drivers/neogeo.cpp neogeo.cpp]]), a few games are known to do this check:

*[[Nightmare in the Dark]] (can be disabled with an RTS at $19978)
*[[The King of Fighters 2000]]
*[[Sengoku 3]]: MVS SLOT CHECK Ver2.30 00/04/25
*[[Matrimelee]]
*[[Metal Slug 2]]
*[[Metal Slug 5]]
* [[Sengoku 3]]: Checks M1 ROM too, displays "M1-ROM ERROR." if Z80 doesn't reply to command 1 in $7FFF iterations loop.

[[Category:Games]]

Puzzle Bobble

2026-08-14T21:22:36Z

Furrtek:

{{GameInfo|right
|en_title=Bust-A-Move
|jp_title=Puzzle Bobble
|jp_title2=パズルボブル
|eu_title=Puzzle Bobble
|developer=Taito
|ngh_id=083
|megcount=32
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=pbobblen
|mvs_date=1994
|mvs_pchip=
|mvs_pboard=PROGTOP
|mvs_cboard=CHA256
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=27/04/95
}}

Many [[Power Spikes II]] MVS cartridges were converted to Puzzle Bobble by SNK by doing the following:
* Replaced the Power Spikes II P1 ROM by the Puzzle Bobble "d96-07" P1 ROM in the EP1 spot.
* Replaced the Power Spikes II V3 ROM by the Puzzle Bobble "d96-01" V3 ROM, also added the "d96-05" V4 ROM.
* Replaced the Power Spikes II C5 and C6 ROMs by the Puzzle Bobble "d96-02" C5 ROM and "d96-03" C6 ROM.
* Replaced the Power Spikes II S1 ROM by the Puzzle Bobble "d96-04" S1 ROM.
* Replaced the Power Spikes II M1 ROM by the Puzzle Bobble "d96-06" M1 ROM.

To probably save on manual labor, the unused Power Spikes II V1, V2, C1, C2, C3 and C4 ROMs were not removed. [[ADPCM]] samples and sprite tile numbers have an offset to skip over the Power Spikes II data.

[[Category:Games]]

Puzzle Bobble

2026-08-14T21:22:27Z

Furrtek:

{{GameInfo|right
|en_title=Bust-A-Move
|jp_title=Puzzle Bobble
|jp_title2=パズルボブル
|eu_title=Puzzle Bobble
|developer=Taito
|ngh_id=083
|megcount=32
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=pbobblen
|mvs_date=1994
|mvs_pchip=
|mvs_pboard=PROGTOP
|mvs_cboard=CHA256
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=27/04/95
}}

Some [[Power Spikes II]] MVS cartridges were converted to Puzzle Bobble by SNK by doing the following:
* Replaced the Power Spikes II P1 ROM by the Puzzle Bobble "d96-07" P1 ROM in the EP1 spot.
* Replaced the Power Spikes II V3 ROM by the Puzzle Bobble "d96-01" V3 ROM, also added the "d96-05" V4 ROM.
* Replaced the Power Spikes II C5 and C6 ROMs by the Puzzle Bobble "d96-02" C5 ROM and "d96-03" C6 ROM.
* Replaced the Power Spikes II S1 ROM by the Puzzle Bobble "d96-04" S1 ROM.
* Replaced the Power Spikes II M1 ROM by the Puzzle Bobble "d96-06" M1 ROM.

To probably save on manual labor, the unused Power Spikes II V1, V2, C1, C2, C3 and C4 ROMs were not removed. [[ADPCM]] samples and sprite tile numbers have an offset to skip over the Power Spikes II data.

[[Category:Games]]

Mahjong controller

2026-08-02T21:53:14Z

Furrtek: /* Software */

[[File:Mahjong_controller.jpg|right|thumb|Mahjong controller]]
[[File:Mahjong_IO.png|right|thumb|Mahjong specific I/O test screen (Japan-J3 system ROM)]]

A special controller designed to play mahjong games. It provides 21 push buttons organized in two rows:

* First row: A B C D E F G H I J K L M N.
* Second row: SELECT START, then PON CHI KAN REACH RON (Japanese: pon chî kan rîchi ron).

=Software=

The mahjong controller is suported by all original [[system ROM]]s.

The MVS system ROM doesn't detect the controller, but reads [[hardware DIPs]] #3 and sets the [[BIOS RAM locations|status byte of INPUT_1]] to 3 if set. It never sets INPUT_2 to 3, meaning that the mahjong controller is a single-player setup only on MVS.

The home console system ROM can detect the controller on both ports (by asserting OUT3 and reading the SELECT button) and sets the corresponding input status byte to 3, allowing the use of two mahjong controllers.

Calling [[SYSTEM_IO]] reports the controller's status and updates the input data in RAM.

=Hardware=

The controller is built using a multiplexed array of buttons, using the controller port outputs to select which group of buttons to read. OUT3 and SELECT are hardwired to enable detection of the controller by home systems.

The button array is organized as follows:

{|class="wikitable"
|
|align="center"|'''OUT1'''
|align="center"|'''OUT2'''
|align="center"|'''OUT3'''
|-
|'''UP'''
|align="center"|A
|align="center"|H
|align="center"|PON
|-
|'''DOWN'''
|align="center"|B
|align="center"|I
|align="center"|CHI
|-
|'''LEFT'''
|align="center"|C
|align="center"|J
|align="center"|KAN
|-
|'''RIGHT'''
|align="center"|D
|align="center"|K
|align="center"|RON
|-
|'''A'''
|align="center"|E
|align="center"|L
|align="center"|REACH
|-
|'''B'''
|align="center"|F
|align="center"|M
|align="center"|-
|-
|'''C'''
|align="center"|G
|align="center"|N
|align="center"|-
|}

SELECT and START are always enabled.

Schematic of the controller:

[[File:Mahjong_schematic.png]]

[[Category:Controllers]]

Joypad

2026-08-02T20:33:44Z

Furrtek:

Regular NeoGeo joypads or joysticks have 4 directions and 6 button switches.

Registers used to read the switches states are {{Reg|REG_P1CNT}}, {{Reg|REG_P2CNT}}, and {{Reg|REG_STATUS_B}}.

The [[SYSTEM_IO]] ($C0044A) [[BIOS calls|BIOS call]] can be used to read inputs more easily: it sets values in the [[BIOS_RAM_locations|BIOS RAM]] which gives currently pressed, state change, and repeat values for both joypads ports.

Only one output is used: [[Pinouts|OUT3]], which is connected to the D button input. This loop is used for detection (D = 0 if OUT3 asserted).

==NeoGeo CD joypads==

[[File:G9pinout.png|right|thumb|"G9" internal schematic. Pin 2 is ground, 1 and 3 are buttons, 4 and 5 are port inputs.]]

[[File:Ngcdpad.jpg|400px]]

The NeoGeo CD joypads use membrane switches and springs for the 4 directions (replacement part ?) which directly set the corresponding inputs to ground.

The buttons are buffered with 3 dual NPN "digital transistors" marked G9, providing good press detection even if the carbon contacts have high resistance.

[[Category:Base system]]
[[Category:Controllers]]

NEO-FTC1B board

2026-08-02T19:39:07Z

Furrtek:

[[File:Ftc1b.jpg|thumb|Picture courtesy of [[http://www.mvs-scans.com MVS-Scans]]. EDGE1 is on the right, EDGE2 on the left.]]

[[Multiplayer]] [[extension board]] used with [[Kizuna Encounter - Super Tag Battle]] to allow 4 players to play on the same system. It forms a Y splitter with 2 [[JAMMA connector pinout|JAMMA]] edges to connect two displays, two pair of speakers and two sets of 2-player controls.

It multiplexes the inputs by using selection signals coming from a 4-wire (actually 2 used) cable that connects to the [[output port]] of the {{PCB|MV1B}} or {{PCB|MV1C}}, it also provides video signal buffering and power for the speakers ([[power amp]] under the heatsink).

=Inputs=

The {{Reg|REG_POUTPUT}} register is used to detect the board and select which set of inputs to read. The logic takes into consideration that the control signals aren't inverted on the MV1B and MV1C output ports.
* OUT1: set selection
* OUT2: unused
* OUT3: used for board detection by some versions of the [[system ROM]]

{|class="wikitable"
!OUT1||P1 reads||P2 reads
|-
|low||EDGE 1 P1 (P1)||EDGE 2 P1 (P2)
|-
|high||EDGE 1 P2 (P3)||EDGE 2 P2 (P4)
|}

When OUT3 is high, it simulates presses on particular buttons:
* EDGE 1 player 1 (P1) button A
* EDGE 2 player 1 (P2) button A
* EDGE 1 player 2 (P3) button B
* EDGE 2 player 2 (P4) button B

=Schematic=

[[File:Ftc1b_schematic.png|800px]]

[[Category:Cartridge systems]]
[[Category:Chips]]

Output port

2026-08-02T19:37:02Z

Furrtek:

Connector on some MVS boards (like the {{PCB|MV1B}}) which do not have DA-15 [[Pinouts|joypad connectors]], used to obtain the 6 output lines for special controllers such as [[trackball]]s.

Warning: these output lines come straight from {{Chipname|NEO-SDR-T}} chips through resistors and not from open-collector inverters like on joypad port equipped systems ! This means that their state might not be inverted in relation to the {{Reg|REG_POUTPUT}} register.

[[Category:Cartridge systems]]

Mahjong controller

2026-07-26T22:14:41Z

Furrtek: /* Software */

[[File:Mahjong_controller.jpg|right|thumb|Mahjong controller]]
[[File:Mahjong_IO.png|right|thumb|Mahjong specific I/O test screen (Japan-J3 system ROM)]]

A special controller designed to play mahjong games. It provides 21 push buttons organized in two rows:

* First row: A B C D E F G H I J K L M N.
* Second row: SELECT START, then PON CHI KAN REACH RON (Japanese: pon chî kan rîchi ron).

=Software=

The mahjong controller is suported by all original [[system ROM]]s.

The MVS system ROM doesn't detect the controller, but reads [[hardware DIPs]] #3 and sets the [[BIOS RAM locations|status byte of INPUT_1]] to 3 if set. It never sets INPUT_2 to 3, meaning that the mahjong controller is a single-player setup only on MVS.

The home console system ROM can detect the controller on both ports (by writing 1 to OUT3 and reading the SELECT button) and sets the corresponding input status byte to 3, allowing the use of two mahjong controllers.

Calling [[SYSTEM_IO]] reports the controller's status and updates the input data in RAM.

=Hardware=

The controller is built using a multiplexed array of buttons, using the controller port outputs to select which group of buttons to read. OUT3 and SELECT are hardwired to enable detection of the controller by home systems.

The button array is organized as follows:

{|class="wikitable"
|
|align="center"|'''OUT1'''
|align="center"|'''OUT2'''
|align="center"|'''OUT3'''
|-
|'''UP'''
|align="center"|A
|align="center"|H
|align="center"|PON
|-
|'''DOWN'''
|align="center"|B
|align="center"|I
|align="center"|CHI
|-
|'''LEFT'''
|align="center"|C
|align="center"|J
|align="center"|KAN
|-
|'''RIGHT'''
|align="center"|D
|align="center"|K
|align="center"|RON
|-
|'''A'''
|align="center"|E
|align="center"|L
|align="center"|REACH
|-
|'''B'''
|align="center"|F
|align="center"|M
|align="center"|-
|-
|'''C'''
|align="center"|G
|align="center"|N
|align="center"|-
|}

SELECT and START are always enabled.

Schematic of the controller:

[[File:Mahjong_schematic.png]]

[[Category:Controllers]]

Trackball

2026-07-26T21:54:45Z

Furrtek:

[[File:Irrmaze_bios1.png|right]]

Special controller only used in [[The Irritating Maze]] cabs.

Works the same way as an upside-down mechanical mouse. Uses two optical encoders for X and Y movement, handled by the [[SIT board]].

A special [[system ROM]] is used (236-bios.sp1).

The counter values are read from {{Reg|REG_P1CNT}}:

* The X counter value when bit 0 of {{Reg|REG_POUTPUT}} is 0.
* The Y counter value when bit 0 of {{Reg|REG_POUTPUT}} is 1.

Speed and direction are computed from the counter deltas.

[[Category:Controllers]]

Displaying credits

2026-07-22T01:31:43Z

Furrtek:

The [[system ROM]] takes care of displaying the credits on the LED displays itself (see [[MV-LED]] board).

It's however the game's duty to display the counts on the screen.

In MVS mode, the credit count for each player is stored in BCD in $D00034 for player 1, and $D00035 for player 2. These locations are in the [[backup RAM]], to keep the credit counts in case of a power failure during play.

'''Note''': [[SYSTEM_IO]] must be called each v-blank to properly update those locations.

There's no call or signal from the [[system ROM]] when coins are inserted so games should refresh this display every frame. SNK recommends doing so by using a 8x8 [[fix layer]] font on the bottom of the screen.

In AES mode, it's up to the game to keep its own credits count in [[68k user RAM]].

<syntaxhighlight>
moveq.l #0,d0
move.b $D00034,d0 ; Read P1 credits (hex)
move.w #$7088,REG_VRAMADDR ; Set position in fix map, top left
move.w d0,d1 ; Make a copy of the BCD value
move.w #$20,REG_VRAMMOD ; Auto-inc fix column
lsr.b #4,d1 ; Get tens
andi.w #$000F,d1 ; Mask off eventual garbage
ori.w #$5030,d1 ; Set palette 5 and tile offset $30 (ASCII "0")
move.w d1,REG_VRAMRW ; Write tens to VRAM
andi.w #$000F,d0 ; Get units
ori.w #$5030,d0 ; Same
move.w d0,REG_VRAMRW ; Write units to VRAM
</syntaxhighlight>

[[Category:Code]]

BIOS RAM locations

2026-07-22T00:17:51Z

Furrtek: /* System Related */

The locations are (?) guaranteed to be identical accross all [[system ROM]] versions so that games can use them regardless of the system type.

=Game Related=

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FD84~$10FD93
|BIOS_GAME_DIP
|16 bytes
|BIOS
|[[Software DIPs]] values (game configuration)
|-
|$10FDAE
|BIOS_USER_REQUEST
|byte
|BIOS
|Request code for the [[USER subroutine]]. 0:Init, 1:Boot animation, 2:Demo, 3:Title
|-
|$10FDAF
|BIOS_USER_MODE
|byte
|BIOS/Game
|Used by the game to tell what it's doing: 0:Init/Boot animation, 1:Title/Demo, 2:Game
[[Game selection]] can only be done on MVS systems when this byte is < 2
|-
|$10FDB0
|BIOS_CREDIT_DEC
|4 bytes
|Game
|Credit decrement value for each player (1, 2, 3, 4) when calling [[CREDIT DOWN]].
|-
|$10FDB4
|BIOS_START_FLAG
|byte
|BIOS
|Used when calling the [[PLAYER START subroutine]]. The 4 LSBs correspond to the player who pushed start.
|-
|$10FDB6
|BIOS_PLAYER_MOD1
|byte
|Game
|rowspan="4|Sets player status. 0:Never played, 1:Playing, 2:Continue option being displayed, 3:Game over
|-
|$10FDB7
|BIOS_PLAYER_MOD2
|byte
|Game
|-
|$10FDB8
|BIOS_PLAYER_MOD3
|byte
|Game
|-
|$10FDB9
|BIOS_PLAYER_MOD4
|byte
|Game
|-
|$10FEC5
|BIOS_TITLE_MODE
|byte
|BIOS/Game
|Newer games set this to 1 in their command 3 [[USER subroutine]]. It prevents the system ROM from calling command 3 twice after game over if credits are already in the system.
|}

=System Related=

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FD80
|BIOS_SYSTEM_MODE
|byte
|BIOS
|0:BIOS wants vblank (system mode), $80:Ok to use vblank (game mode)
|-
|$10FD81
|BIOS_SYSRET_STATUS
|byte
|BIOS
|Internal value which stores the function code that [[SYSTEM_RETURN]] will call.
*0 : Init bram/select valid game for eye-catcher
*1 : Set the EL-LED to the correct value
*2 : Switch to the next slot, relaunch eye-catcher
*3 : After a gameover, save the playtime for bookeeping, switch to DEMO mode, reset the workbackup ram
*4 : Switch next slot (select p1 pressed)
*5 : Switch to previous slot (select p2 pressed)
*6 : Called after a coin deposit, does nothing
|-
|$10FD82
|BIOS_MVS_FLAG
|byte
|BIOS
|System type. 0:AES, 0x80:MVS
|-
|$10FD83
|BIOS_COUNTRY_CODE
|byte
|BIOS
|0:Japan, 1:USA, 2:Europe
|-
|$10FE80
|BIOS_DEVMODE
|8 bytes
|BIOS
|All set to 0x00 in normal mode. Set to "1streset" string in developer mode
|}

=Joypad Related=

These values are updated by calling [[SYSTEM_IO]].

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FD94
|BIOS_P1STATUS
|byte
|BIOS
|0:No connection, 1:Normal joypad, 2:Expanded joypad, 3:Mahjong controller, 4:Keyboard
|-
|$10FD95
|BIOS_P1PREVIOUS
|byte
|BIOS
|Inputs on previous frame [DCBA Right Left Down Up] (positive logic).
|-
|$10FD96
|BIOS_P1CURRENT
|byte
|BIOS
|Inputs on current frame [DCBA Right Left Down Up] (positive logic).
|-
|$10FD97
|BIOS_P1CHANGE
|byte
|BIOS
|Buttons just pressed, active edge [DCBA Right Left Down Up] (positive logic).
|-
|$10FD98
|BIOS_P1REPEAT
|byte
|BIOS
|Active edge + repeat every 8 frames after 16 frames. [DCBA Right Left Down Up] (positive logic).
|-
|$10FD99
|BIOS_P1TIMER
|byte
|BIOS
|Repeat timer (counts down from 8 to 0).
|-
|$10FD9A~$10FD9F
|Same for P2
|6 bytes
|BIOS
|See above
|-
|$10FDA0~$10FDA6
|Same for P3
|6 bytes
|BIOS
|See above
|-
|$10FDA7~$10FDAB
|Same for P4
|6 bytes
|BIOS
|See above
|-
|$10FDAC
|BIOS_STATCURNT
|byte
|BIOS
|Select P4, Start P4, Select P3, Start P3, Select P2, Start P2, Select P1, Start P1 (positive logic)

On MVS the select bits are always read as 0.
|-
|$10FDAD
|BIOS_STATCHANGE
|byte
|BIOS
|Select P4, Start P4, Select P3, Start P3, Select P2, Start P2, Select P1, Start P1 (positive logic)

On MVS the select bits are always read as 0.
|-
|$10FEDC
|BIOS_STATCURNT_RAW
|byte
|BIOS
|Select P4, Start P4, Select P3, Start P3, Select P2, Start P2, Select P1, Start P1 (positive logic)
|-
|$10FEDD
|BIOS_STATCHANGE_RAW
|byte
|BIOS
|Select P4, Start P4, Select P3, Start P3, Select P2, Start P2, Select P1, Start P1 (positive logic)
|}

=Memory Card Related=

See [[CARD]] for more details on those variables.

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FDC4
|BIOS_CARD_COMMAND
|byte
|BIOS or Game
|Command to execute
|-
|$10FDC5
|BIOS_CARD_MODE
|byte
|BIOS?
|Internal use?
|-
|$10FDC6
|BIOS_CARD_ANSWER
|byte
|BIOS
|Answer code for the command
|-
|$10FDC8
|BIOS_CARD_START
|longword
|BIOS or Game
|Pointer to data
|-
|$10FDCC
|BIOS_CARD_SIZE
|word
|BIOS or Game
|Size of data
|-
|$10FDCE
|BIOS_CARD_FCB
|word
|BIOS or Game
|Game NGH number
|-
|$10FDD0
|BIOS_CARD_SUB
|byte or word
|BIOS or Game
|Game Subnumber
|}

=MESS OUT Related=

See [[MESS_OUT]] to know how to use this routine.

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FDBE
|BIOS_MESS_POINT
|longword
|Game
|Buffer pointer
|-
|$10FDC2
|BIOS_MESS_BUSY
|byte
|Game
|0:Allow MESS_OUT, 1:Skip MESS_OUT
|}

=Calendar Related=

Those value are updated when [[READ_CALENDAR]] is called

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FDD2
|BIOS_YEAR
|byte
|BIOS
|Current year
|-
|$10FDD3
|BIOS_MONTH
|byte
|BIOS
|Current month
|-
|$10FDD4
|BIOS_DAY
|byte
|BIOS
|Current day
|-
|$10FDD5
|BIOS_WEEKDAY
|byte
|BIOS
|Current weekday (Sunday = 00, Monday = 01 ... Saturday = 06)
|-
|$10FDD6
|BIOS_HOUR
|byte
|BIOS
|Current hour (24h format)
|-
|$10FDD7
|BIOS_MINUTE
|byte
|BIOS
|Current minute
|-
|$10FDD8
|BIOS_SECOND
|byte
|BIOS
|Current minute
|}

=Internal=

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FCEF
|BIOS_SLOTCHECK
|byte
|BIOS
|[[Slot check]] passed if non-zero
|-
|$10FDDA
|BIOS_COMPULSION_TIMER
|byte
|BIOS
|Timer for the game compulsion start feature, in seconds. BCD format.
|-
|$10FDDB
|BIOS_COMPULSION_FRAME_TIMER
|byte
|BIOS
|Frame-based timer for the game compulsion start feature.

When it underflows, the timer is reset to 59 and START_COMPULSION_TIMER is decremented.
|-
|$10FE88
|BIOS_FRAME_COUNTER
|longword
|BIOS
|Frame counter, updated by SYSTEM_IO.
|-
|$10FEBF
|BIOS_BRAM_USED
|byte
|BIOS
|0:[[Backup RAM]] not currently used, 1:Currently used
|-
|$10FEE1
|BIOS_FRAME_SKIP
|byte
|BIOS
|Number of frames to skip in the routine which checks demo_end or if the player has pressed start.

Decremented in [[SYSTEM_IO]].
|-
|$10FEE3
|BIOS_INT1_SKIP
|byte
|BIOS
|Only used in [[SYSTEM_INT1]]. If non-zero, will only do the [[RTC]] check during INT1.
|-
|$10FEE4
|BIOS_INT1_FRAME_COUNTER
|byte
|BIOS
|Frame counter, only used in [[SYSTEM_INT1]]
|}

=4P mode related=

Thoses will be valid on a 4P compatible bios only

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FEF8
|BIOS_4P_REQUESTED
|byte
|BIOS
|Keeps a local copy of hard dip 2 status on bootup.

0: dip2 wasn't set

$2: dip 2 was on.
|-
|$10FEFA
|BIOS_4P_MODE
|byte
|BIOS
|Main 4P flag, is set when hard dip 2 is on and 4P board is found.

0: regular play

$FF: 4P mode game
|-
|$10FEFB
|BIOS_4P_PLUGGED
|byte
|BIOS
|0: 4P board not found

$FF: 4P board plugged

4P compatible bios will check for 4P board regardless of dip2 switch status.
|}

=CD only=

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FEF4
|BIOS_UPDEST
|Long
|Game
|Copy destination address
|-
|$10FEF8
|BIOS_UPSRC
|Long
|Game
|Copy source address
|-
|$10FEFC
|BIOS_UPSIZE
|Long
|Game
|Copy data size
|-
|$10FEDA
|BIOS_UPZONE
|Byte
|Game
|Copy zone (0=PRG, 1=FIX, 2=SPR, 3=Z80, 4=PCM, 5=PAT, 7=OBJ, 8=A** files)
|-
|$10FEDB
|BIOS_UPBANK
|Byte
|Game
|Copy bank
|}

=Others=

{| class="regdef"
| '''Address'''
| '''DEF name'''
| '''Size'''
| '''Set by'''
| '''Description'''
|-
|$10FCEE
|?
|byte
|GAME
|Z80/M ROM check pass

|}

[[Category:Base system]]

Memory speed

2026-07-21T18:32:45Z

Furrtek:

[[File:Aes_cxk5814.jpg|thumb|[[VRAM]] chip, note the "-35" marking. 35ns is the highest speed requirement in the NeoGeo.]]

Memory speed (or speed grade) is a value representing the maximum time it takes for a memory chip to output valid data after its address is changed.

It is essential for memory chips to be fast enough to avoid crashes or glitches. When replacing RAMs, replacing the [[system ROM]] or making cartmods, care must be taken to use chips with the appropriate speed grades.

Speed is usually indicated on the chip. It is actually a time value (speed = 1/t) specified in nanoseconds or tens of nanoseconds.

The data output is only guaranteed to be valid after the specified time. So if the chip is too slow, the system might read corrupt data resulting in unstable operation.

Regarding the NeoGeo and most other systems, faster than required (lower value) isn't a problem, slower than required (higher value) is bad.

A slower chip can work in some cases if you're lucky, but you should never expect stable operation in all conditions. For example, some 120ns chips might work in place of a 100ns one, but a slight variation in voltage or temperature could cause crashes or resets. Taking the risk isn't worth it.

=Requirements summary=

See the related section in the [[VRAM]], [[Palette RAM]], [[P ROM]], [[V ROM]], [[S ROM]], [[C ROM]], and [[M1 ROM]] pages.

{|class="wikitable"
!Memory kind
!Maximum value
!Mclks
!Proof
|-
|Z80 RAM
|rowspan="2"|<500ns (2 MHz)
|rowspan="2"|12? (500ns)
|rowspan="2"|Z80 read cycle
|-
|M1 ROM
|-
|Lower VRAM
|120ns (8.33 MHz)
|3 (125ns)
|Picture
|-
|Upper VRAM
|35ns (28.57 MHz)
|1 (41.7ns)
|Picture
|-
|Palette RAM
|120ns (8.33 MHz)
|3 (125ns)
|Picture
|-
|L0 ROM
|120ns ? (8.33 MHz)
|?
|
|-
|P ROM
|rowspan="4"|250ns
|rowspan="4"|6 (3 68k clocks) ?
|-
|System ROM
|-
|68k RAM
|-
|Backup RAM
|-
|V ROM
|200ns (5 MHz)
|6 (250ns)
|YM2610 read cycle
|-
|S ROM
|200ns ? (5 MHz)
|5? (208ns)
|
|-
|C ROM
|200ns ? (5 MHz)
|5? (208ns)
|
|-
|Memory card
|417ns ?
|10 (3 68k clocks + 2 waits) ?
|
|}

=Standard speed grades=

* -250 (250ns)
* -200 '''or -20''' (200ns)
* -150 '''or -15''' (150ns)
* -120 '''or -12''' (120ns)
* -90 (90ns)
* -70 (70ns)
* -55 (55ns)
* -35 (35ns).

Note the possible confusion. If the value is less than 30 you probably have to add a 0, even if SRAM is now available in 25ns (not 250ns) speed grades.

Check the datasheets.

=DRAM=

DRAM (CD systems) is way more complex than SRAM, timings and sequences are primordial.

[[Category:Chips]]
[[Category:Base system]]
[[Category:Repairs]]

L0 ROM

2026-07-20T01:26:16Z

Furrtek:

[[File:aes_lo.jpg|right|thumb|Toshiba LO ROM chip taken from an AES system.]]
[[File:cd2_lo.jpg|right|thumb|LO ROM chip found on a CDM3-2 board.]]

The L0 ROM is a 64KiB [[Sprite_shrinking|sprite scaling]] lookup table found in every NeoGeo system as a standalone mask ROM or integrated in {{chipname|NEO-GRZ}}.

The 000-lo.lo dump commonly found in [[system ROM]] sets is 128KiB but only the first half is used.

=Hash=

* CRC32: 5A86CFF2
* SHA-1: 5992277DEBADEB64D1C1C64B0A92D9293EAF7E4A

=Data format=

The data is made of 256 tables of 256 bytes, each table corresponding to a vertical shrinking value for sprites.

For the first 256 lines (top half of a full sprite), the index in the table is the pixel row number of the sprite currently being drawn (scanline - Y position).

Each byte entry in the table is used as 2 nibbles:
*The upper nibble is the index to read in the tilemap in [[VRAM]] SCB1 (0 to 15).
*The lower nibble is the pixel row number of that tile to fetch in the [[C ROM]]s.

For the last 256 lines (bottom half of a full sprite), the index in the table is complemented: the table is read backwards.

*The upper nibble is the index XOR 31 to read in the tilemap in VRAM SCB1 (16 to 31).
*The lower nibble is the pixel row number XOR 15 of that tile to fetch in the C ROMs.

==Example of GPU processing==
[[File:Ngscaling.png|right|thumb]]

(Maybe place this part in the LSPC page ?)

Sprite with Y scaling value = $1B (10.6% of full size).

{|class=wikitable
!Sprite line #
!L0 address
!L0 data
!Tilemap index
!Pixel row in tile
|-
|0||$1B00||$00||0||0
|-
|1||$1B01||$08||0||8
|-
|2||$1B02||$10||1||0
|-
|colspan=5|...
|-
|26||$1B1A||$E8||14||8
|-
|27||$1B1B||$F8||15||8
|-
|28||$1B1C||$FF||15||15
|-
|29||$1B1D||$FF||15||15
|-
|colspan=5|...
|}

==Datasheet==
There are 2 stand alone chip versions used depending on the NeoGeo system, the SOP32 TC531001 and the DIP28 TC531000.

Official TC531001 datasheet: [[http://www.alldatasheet.com/datasheet-pdf/pdf/115078/TOSHIBA/TC531001.html]]

Official TC531000 datasheet: [[https://www.digchip.com/datasheets/parts/datasheet/710/TC531000CP-pdf.php]]

[[Category:Chips]]

Sprite shrinking

2026-07-20T01:23:13Z

Furrtek: /* Vertical shrinking */

Shrinking (also known as scaling, reduction, and "zooming") is a hardware feature of the NeoGeo which allows to scale down [[sprites]] with per-pixel accuracy in both dimensions.

Shrinking is performed by [[LSPC]] by skipping a variable number of pixel lines or columns. It can be seen as a simple subsampling of the original graphics since there's no smoothing applied at all.

=Vertical shrinking=

The vertical shrinking is set by an 8-bit value specifying the final height of the sprite's '''graphics'''. This value is set in [[VRAM]], in the [[Sprites|SCB2]].

Range: $FF is the tallest (1:1 size), $0 is the smallest (1:256).

To know which line to skip, LSPC uses a lookup table stored in the {{Chipname|L0 ROM}}.

The vertical shrink parameter propagates in [[Sticky bit|chained sprites]].

==Caveat: Display window==

Note that vertical shrinking does not affect the tile height setting of the sprite. The graphics are shrunk '''inside''' the defined window.

<gallery>
File:spritez_4.png|Sprite height set to 4 tiles, graphics intentionally filling 4 tiles
File:spritez_3.png|The same sprite updated to be only 3 tiles high without clearing the 4th (yellow) tile
File:spritez_anim.gif|The sprite will shrink this way, showing the garbage yellow tile from the previous setup
</gallery>

==Caveat: Last line repeat==

If the display window of a sprite is taller than 16 tiles worth of shrunk graphics, the remaining lines will be filled with repeats of the last line of the last tile (the bottom line of the tile at map index 15). This is because there's no logic to mask out those lines, only $FF padding values from the L0 ROM.

SNK recommends leaving that line fully transparent if this causes problems.

=Horizontal shrinking=

The horizontal shrinking is set by a 4-bit value specifying the final width of the sprite graphics +1 (giving 1 to 16 pixels wide sprites). This value is also set in [[Sprites|SCB2]].

Range: $F is full size (all 16 pixels shown), $0 is the smallest (only 1 pixel shown).

The horizontal shrink parameter does '''not''' propagate in chained sprites. Values for each sprite of a group [[Scaling sprite groups|have to be distributed]] to obtain the total desired group width.

There is no external lookup table for horizontal shrinking. The process is completely done inside LSPC.
In the following table, each line corresponds to a shrinking value. 1 means the pixel will be drawn and 0 means it will be skipped (info from MAME's source, matches the real hardware):

[[File:Hshrink.gif|thumb|Horizontal shrink effect on a multicolored tile, showing how pixels are skipped.]]

*0: 0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0 (15 pixel skipped, 1 remaining)
*1: 0,0,0,0,1,0,0,0,1,0,0,0,0,0,0,0 (14 pixels skipped...)
*2: 0,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0
*3: 0,0,1,0,1,0,0,0,1,0,0,0,1,0,0,0
*4: 0,0,1,0,1,0,0,0,1,0,0,0,1,0,1,0
*5: 0,0,1,0,1,0,1,0,1,0,0,0,1,0,1,0
*6: 0,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0
*7: 1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0
*8: 1,0,1,0,1,0,1,0,1,1,1,0,1,0,1,0
*9: 1,0,1,1,1,0,1,0,1,1,1,0,1,0,1,0
*A: 1,0,1,1,1,0,1,0,1,1,1,0,1,0,1,1
*B: 1,0,1,1,1,0,1,1,1,1,1,0,1,0,1,1
*C: 1,0,1,1,1,0,1,1,1,1,1,0,1,1,1,1
*D: 1,1,1,1,1,0,1,1,1,1,1,0,1,1,1,1
*E: 1,1,1,1,1,0,1,1,1,1,1,1,1,1,1,1 (...1 pixel skipped)
*F: 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 (no pixels skipped, full size)

=Centering=

Centering can be required since the "anchor point" of sprites is fixed at their top left corner.

Todo: code example.

[[Category:Video system]]

Sprite shrinking

2026-07-20T01:20:10Z

Furrtek: /* Caveat: Last line repeat */

Shrinking (also known as scaling, reduction, and "zooming") is a hardware feature of the NeoGeo which allows to scale down [[sprites]] with per-pixel accuracy in both dimensions.

Shrinking is performed by [[LSPC]] by skipping a variable number of pixel lines or columns. It can be seen as a simple subsampling of the original graphics since there's no smoothing applied at all.

=Vertical shrinking=

The vertical shrinking is set by an 8-bit value specifying the final height of the sprite's '''graphics'''. This value is set in [[VRAM]], in the [[Sprites|SCB2]].

Range: $FF is the tallest, $0 is the smallest.

To know which line to skip, LSPC uses a lookup table stored in the {{Chipname|L0 ROM}}.

The vertical shrink parameter propagates in [[Sticky bit|chained sprites]].

==Caveat: Display window==

Note that vertical shrinking does not affect the tile height setting of the sprite. The graphics are shrunk '''inside''' the defined window.

<gallery>
File:spritez_4.png|Sprite height set to 4 tiles, graphics intentionally filling 4 tiles
File:spritez_3.png|The same sprite updated to be only 3 tiles high without clearing the 4th (yellow) tile
File:spritez_anim.gif|The sprite will shrink this way, showing the garbage yellow tile from the previous setup
</gallery>

==Caveat: Last line repeat==

If the display window of a sprite is taller than 16 tiles worth of shrunk graphics, the remaining lines will be filled with repeats of the last line of the last tile (the bottom line of the tile at map index 15). This is because there's no logic to mask out those lines, only $FF padding values from the L0 ROM.

SNK recommends leaving that line fully transparent if this causes problems.

=Horizontal shrinking=

The horizontal shrinking is set by a 4-bit value specifying the final width of the sprite graphics +1 (giving 1 to 16 pixels wide sprites). This value is also set in [[Sprites|SCB2]].

Range: $F is full size (all 16 pixels shown), $0 is the smallest (only 1 pixel shown).

The horizontal shrink parameter does '''not''' propagate in chained sprites. Values for each sprite of a group [[Scaling sprite groups|have to be distributed]] to obtain the total desired group width.

There is no external lookup table for horizontal shrinking. The process is completely done inside LSPC.
In the following table, each line corresponds to a shrinking value. 1 means the pixel will be drawn and 0 means it will be skipped (info from MAME's source, matches the real hardware):

[[File:Hshrink.gif|thumb|Horizontal shrink effect on a multicolored tile, showing how pixels are skipped.]]

*0: 0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0 (15 pixel skipped, 1 remaining)
*1: 0,0,0,0,1,0,0,0,1,0,0,0,0,0,0,0 (14 pixels skipped...)
*2: 0,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0
*3: 0,0,1,0,1,0,0,0,1,0,0,0,1,0,0,0
*4: 0,0,1,0,1,0,0,0,1,0,0,0,1,0,1,0
*5: 0,0,1,0,1,0,1,0,1,0,0,0,1,0,1,0
*6: 0,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0
*7: 1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0
*8: 1,0,1,0,1,0,1,0,1,1,1,0,1,0,1,0
*9: 1,0,1,1,1,0,1,0,1,1,1,0,1,0,1,0
*A: 1,0,1,1,1,0,1,0,1,1,1,0,1,0,1,1
*B: 1,0,1,1,1,0,1,1,1,1,1,0,1,0,1,1
*C: 1,0,1,1,1,0,1,1,1,1,1,0,1,1,1,1
*D: 1,1,1,1,1,0,1,1,1,1,1,0,1,1,1,1
*E: 1,1,1,1,1,0,1,1,1,1,1,1,1,1,1,1 (...1 pixel skipped)
*F: 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 (no pixels skipped, full size)

=Centering=

Centering can be required since the "anchor point" of sprites is fixed at their top left corner.

Todo: code example.

[[Category:Video system]]

Puzzle Bobble

2026-07-19T15:25:27Z

Furrtek:

{{GameInfo|right
|en_title=Bust-A-Move
|jp_title=Puzzle Bobble
|jp_title2=パズルボブル
|eu_title=Puzzle Bobble
|developer=Taito
|ngh_id=083
|megcount=32
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=pbobblen
|mvs_date=1994
|mvs_pchip=
|mvs_pboard=PROGBK1
|mvs_cboard=CHA256
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=27/04/95
}}

Some [[Power Spikes II]] MVS cartridges were converted to Puzzle Bobble by SNK by doing the following:
* Replaced the Power Spikes II P1 ROM by the Puzzle Bobble "d96-07" P1 ROM in the EP1 spot.
* Replaced the Power Spikes II V3 ROM by the Puzzle Bobble "d96-01" V3 ROM, also added the "d96-05" V4 ROM.
* Replaced the Power Spikes II C5 and C6 ROMs by the Puzzle Bobble "d96-02" C5 ROM and "d96-03" C6 ROM.
* Replaced the Power Spikes II S1 ROM by the Puzzle Bobble "d96-04" S1 ROM.
* Replaced the Power Spikes II M1 ROM by the Puzzle Bobble "d96-06" M1 ROM.

To probably save on manual labor, the unused Power Spikes II V1, V2, C1, C2, C3 and C4 ROMs were not removed. [[ADPCM]] samples and sprite tile numbers have an offset to skip over the Power Spikes II data.

[[Category:Games]]

Rendering logic

2026-07-18T19:37:04Z

Furrtek: /* Slow VRAM access slots */

Depending on the chipset, video is generated by 3, 2 or one unique chip:

* 3: [[LSPC-A0]], [[PRO-B0]], [[PRO-C0]] (early)
* 2: [[LSPC2-A2]], [[NEO-B1]] (most common)
* 1: [[NEO-GRC]] (CD systems), [[NEO-GRZ]] (CDZ, MV-1C...)

See [[graphics pipeline]] for an overview of the interconnections between chips and cartridges. See [[Display timing]] for the sync signal's timing.

There are two main parts in generating video:

* An address generator (LSPC), which queries the graphics ROMs in the cartridges according to the data set in [[VRAM]].
* Line buffers, to which pixels can be written in any order from the graphics ROMs data.

=Line buffers=

To render sprites, the NeoGeo uses a pair of line buffers which are each 320 pixels long (a whole scanline). When one is used for rendering, the other one is shifted out for video output. Each new scanline, the buffers are flipped. This can be seen as a kind of double-buffering, allowing pixels to be rendered in any order.

To increase bandwidth, pixels are rendered two by two in sub-pairs: there are actually 4, 160-pixels-long buffers interleaved in an odd/even fashion. This scheme was inherited from the [[Alpha68k]].

The fix layer pixels are rendered in real time over the buffers output.

==Fix tiles==

* Fix pixels are output in time with the pixel clock (6MHz, 4mclk).
* One fix tile line is therefore output in: 8 pixels * 4mclk = 32mclk. No variation.
* The S ROM outputs 8 bits at a time so: 8 bits / 4bpp = 2 pixels at a time.
* S ROM reads needed for one fix tile line: 8 pixels / 2 pixels per read = 4 reads.

Address sequence for one tile line:
{|class="wikitable"
! A4 !! 2H1 !! pixel pair
|-
| 1 || 0 || A
|-
| 1 || 1 || B
|-
| 0 || 0 || C
|-
| 0 || 1 || D
|}

2H1 bypasses the PCK* latchs.

==Sprite tiles==
16mclk = 16 pixels, 8 pixels per read.

* Sprite pixels are rendered two-by-two at 12MHz (2mclk).
* One sprite tile line is therefore rendered in: 16 pixels / 2 * 2mclk = 16mclk. No variation, even if shrinking is used.
* The C ROM outputs 2 * 16 = 32 bits at a time so: 32 bits / 4bpp = 8 pixels at a time.
* C ROM reads needed for one sprite tile line: 16 pixels / 8 pixels per read = 2 reads.

Address sequence for one tile line:
{|class="wikitable"
! CA4 !! 8-pixel line
|-
| 1 || A
|-
| 0 || B
|}

CA4 bypasses the PCK* latchs.

=Active lists=

The NeoGeo uses a pair of active lists, where the sprites numbers which need to be rendered on the next scanline are written to. As with the line buffers, the active lists are swapped every new scanline so that one is being filled by parsing, the other one is used for rendering.

They are located in the fast VRAM at addresses $8600 and $8680. Each list is 96-entries long.

=Slow VRAM access slots=

Slow VRAM has four 4mclk-long access slots running in sequence with no variations:

# Read sprite map even word
# Read sprite map odd word
# Read/Write for CPU
# Read fix map

=Fast VRAM access slots=

Fast VRAM is more complex and faster. It has 10 access slots with varying widths running in sequence with no variations, which can be seen as 5 parsing slots and 5 rendering slots:

{|class="wikitable"
! Slot # !! Duration !! Description
|-
|1
|2mclk
|rowspan=5|Parsing
|-
|2
|1.5mclk
|-
|3
|1.5mclk
|-
|4
|1.5mclk
|-
|5
|1.5mclk
|-
|6
|2mclk
|Read active list
|-
|7
|1.5mclk
|Read SCB2
|-
|8
|1.5mclk
|Read SCB3
|-
|9
|1.5mclk
|Read SCB4
|-
|10
|1.5mclk
|Read/write for CPU
|}

Yellow are parsing cycles, purple is the active list read, green is SCB* reads for rendering, red is for CPU access:

[[file:timing_gpu1.png]]

The parsing cycles aren't consistent, they depend on the matching of sprites. One cycle will read from SCB3 to test if its Y position matches with the current raster line. If there's a match, the next cycle will be a write to the active list. Otherwise it's another read cycle.

Fast VRAM must be fast enough (45ns) as the shortest slots are 1.5mclk (62.5ns). 1mclk (41.6ns) would be too fast and SRAM was already expensive.

=Sprite parsing=

This is still a draft. The following information shouldn't be considered as correct.

LSPC splits the workload needed to render sprites in two passes: parsing and rendering.

* Parsing for a raster line N is done during line N-2
* Rendering is done during line N-1
* Finally the line is ready for output just at the right time.

During parsing, the Y positions of 381 sprites are read to see if they will be visible on line N. If that's the case, the sprite number is written to the active list currently being filled. This goes on until 381 sprites were parsed, OR the active list is full (96 sprite numbers were written), whichever comes first.

* If sprite #382 is reached, the remaining time is used to fill the active list up to 96 entries with zeros.
* If the active list is full, sprites are still parsed up to #382 but no writes are done to the active list, whatever the matching result.

No matter how many sprites are matched in the scanline, there will always be 381 SCB3 reads and 96 active list writes.

This explains why sprite #0 cannot be used: this is the value used to top-up the active list. If there are less than 96 sprite matches (like most of the time), the sprite #0 will be rendered over and over again until the end of the list is reached.

In the next paragraphs, each character represents a parsing slot: R is an SCB3 read, W is a sprite number write to the active list, F is a filling write to the active list, - is just idle waiting. There are always 1536mclk per line / 16mclk per cycle * 5 slots per cycle = 480 slots.

==Case 1: Not a single sprite match==

Fast VRAM cycles:
<pre>
24M _|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_
Addr 200 | 201 | 202 | 203 | 204 | 681 | 00E | 20E | 40E | 600 | 205 | 206 | 207 | 208 | 209 | 682 | 00F | 20F | 40F
R/W Read Read Read Read Read Read Read Read Read Read
</pre>

381 read slots, 96 fill slots, 3 waiting slots:
<pre>
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF---
</pre>

==Case 2: Some sprites match==

Fast VRAM cycles:
<pre>
24M _|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_
Addr 200 | 201 | 600 | 202 | 203 | 681 | 00E | 20E | 40E | 600 | 601 | 204 | 205 | 602 | 206 | 682 | 00F | 20F | 40F
R/W Read Read Write Read Read Write Read Read Write Read
</pre>

If 17 sprites match: 381 read slots, 17 write slots, 96-17=79 fill slots, 3 waiting slots:
<pre>
RRRRRRWRRRRRRRRRRRRRRRRRRRRWRRRRRRRRRWRRRRRRWRRRRRRWRRRRRWRWRWRRRRRRRRRWRRRRRRRRRRRRRRWRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRWRWRRRRWRWRRRRRRRRRRRRRRRRRRRRRRRRWRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWRRRWRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF---
</pre>

==Case 3: Exactly 96 sprites match==

Fast VRAM cycles:
<pre>
24M _|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_|'|_
Addr 200 | 600 | 201 | 601 | 202 | 681 | 00E | 20E | 40E | 600 | 602 | 203 | 204 | 603 | 604 | 682 | 00F | 20F | 40F
R/W Read Write Read Write Read Write Read Read Write Read
</pre>

381 read slots, 96 write slots, 0 fill slots, 3 waiting slots:
<pre>
RRRRRRWRRRRWRRRRRRRWRRRRRWRWRWRRWRRRRRRRRRWRRRRRRWRRWRRRRWRRRRRWRWRWRRRRRWRRRRWRRRRRRRRWRRRRRRWRRRWR
WRWRRWRRRRRRRWRRRWRRRWRRRRWRRRRRRRRWRWRRRRWRWRRRRRRRRRRRRRRRRRRRRRRRRWRRRRRRRRRRRRRRWRRRWRWRWRWRRWRW
RRRRWRRWRRWRRRWRRRWRRWRRRRWRWRWRRWRRRWRWRWRRWRRRRWRRRRRWRRWRRWRRRRRRWRRRWRRRRWRRRRRWRRWRRRWRRRWRRRRR
WRWRWRWRWRWRRRWRRRWRRRRRRRWRRRWRWRRRWRRRRRRRRRWRRRRRRRWRWRWRWRRRRRRRRRRWRRWRRRRRRWRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRWRRRWRRRRWRRRWRRRRRRRWRRRRRRRWRRRRWRWRRRWRRWRRRRWRRRRRWRRRRRWR---
</pre>

==Case 4: More than 96 sprites match==

Same as case 3, except after 96 "W"s, there are only useless "R"s.

==Rendering==

# Read active list ($8600+ or $8680+) to get sprite #
# Read SCB2 zoom values ($8000+)
# Read SCB3 Y position, height, and chain bit ($8200+)
# Read SCB4 X position ($8400+)

The tile # and its attributes are also read from slow VRAM.

==CPU access to VRAM==

SNK says min. 12 68kclk between writes (so 24mclk). 1 write every 24mclk = 64 per scanline.

CPU access occurs asynchronously with the 68000 bus -> storage in LSPC. If no write is requested, then the slots are occupied by reads, effectively updating one of the two read buffers continuously with the value pointed by the last used VRAM address.

=Buffers control=

==CK signals==
CK1~4 signals are used to clock each of the 4 buffers.

* During rendering, the pulses often go by pair (1+2 or 3+4) to render pixels 2 by 2 if the corresponding WE signal is asserted (opaque pixel). Horizontal shrinking causes pulses to be skipped, so that the buffer's address isn't incremented.
* During output, the pulses are slower and always alternate (1/2/1/2... or 3/4/3/4...) to output even/odd pixels in sequence.

* If the corresponding LD* signal is high, the buffer pointer is incremented (rendering left to right).
* If the corresponding LD* signal is low, the buffer pointer is loaded from the [[P bus]] (X position of sprite, or 0 to start line output).

Inactive during H-blank.

==LD signals==
The LD1~2 signals are synchronous signals used to load the pointers for a buffer pair as two bytes.

Example P bus values for 5 full-width sprites right next to each other, starting at X=0:

<pre>0000,0808,1010,1818,2020</pre>

Example P bus values for 5 full-width sprites right next to each other, starting at X=1 (pixel pairs will be flipped by NEO-ZMC2):

<pre>0100,0908,1110,1918,2120</pre>

As sprite lines '''always''' take 16mclk to render, there's an LD* pulse every 16mclk to set the new starting address (X position) '''except''' for chained sprites. There's also always an unique pulse just before output to reset the pointers to 0.

==WE signals==
WE1~4 signals are used to tell if the pixel should be written to a buffer.

During rendering, the pulses are synchronized to CK signals.

* If the pixel is opaque, there are both pulses at the same time (write pixel).
* If the pixel is transparent, there is a CK pulse but no WE pulse (skip pixel, move to next one).
* If the pixel is skipped for horizontal shrink, there are no pulses at all (do nothing).

During output, the pulses are also synchronized to CK signals and always present. This is used to clear the buffers to the backdrop color for the next rendering cycle.

==SS signals==
The SS1/2 signals enable clearing of buffer pairs, active during output.

==Others==

* TMS0 is used to flip the buffers, related to the lowest bit of the raster counter.
* The rising edge of PCK1 and PCK2 latches fix or sprite pixels from the cart ROMs.

Fix data is read 8 pixels in advance (32mclk, confirms what Charles wrote in mvstech.txt).

[[Category:Video system]]

Game CD structure

2026-07-09T07:04:43Z

Furrtek:

It seems that the NeoGeo CD wants at least a PRG, FIX, SPR, Z80 and PCM loaded in [[IPL file|IPL.TXT]], or else it will simply reset after loading.

There must be no more than 512 files on the whole CD for the [[system ROM]] loading code to properly work. [[Samurai Shodown RPG]] hates rules and doesn't care about this restriction.

==Recognized files==

From table in [[System ROM]] dumps:
*[[IPL file]] (no type)
*[[PRG file]]s (type 0)
*[[FIX file]]s (type 1)
*[[SPR file]]s (type 2)
*[[Z80 file]]s (type 3)
*[[PCM file]]s (type 4)
*[[PAT file]]s (type 5)
*[[TXT file]]s (no type)
*[[OBJ file]]s (type 7)
*A** files, (type 8) ?
*[[SYS file]]s (type ?)
*others ?

[[Category:CD systems]]

Top Player's Golf

2026-07-09T07:02:44Z

Furrtek:

{{GameInfo|right
|en_title=Top Player's Golf
|jp_title=Top Player's Golf
|jp_title2=トッププレイヤーズゴルフ
|developer=SNK
|ngh_id=003
|megcount=62
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=tpgolf
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-EP
|mvs_cboard=CHA-32
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_romset=tpgolf
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=09/09/94
}}

Uses no custom chips.

[[Category:Games]]

The Super Spy

2026-07-09T07:02:35Z

Furrtek:

{{GameInfo|right
|en_title=The Super Spy
|jp_title=The Super Spy
|jp_title2=ザ・スーパースパイ
|developer=SNK
|ngh_id=011
|megcount=55
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=superspy
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-8MB
|mvs_cboard=CHA-8M
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_romset=superspy
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=09/09/94
}}

Uses no custom chips.

[[Category:Games]]

Riding Hero

2026-07-09T07:02:26Z

Furrtek:

{{GameInfo|right
|en_title=Riding Hero
|jp_title=Riding Hero
|jp_title2=ライディングヒーロー
|developer=SNK
|ngh_id=006
|megcount=46
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=ridhero
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-HERO
|mvs_cboard=CHA-32
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=26/05/95
}}

Uses no custom chips.

[[Category:Games]]

Puzzled

2026-07-09T07:02:15Z

Furrtek:

{{GameInfo|right
|en_title=Puzzled
|jp_title=Joy Joy Kid
|jp_title2=ジョイジョイキッド
|developer=SNK
|ngh_id=021
|megcount=22
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=joyjoy
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-EP
|mvs_cboard=CHA-32
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_date=01/07/91
|aes_romset=joyjoy
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=09/09/94
}}

Smallest game edited for the NeoGeo (~191KiB [[P ROM]]). Uses no custom chips.

The CD version of the game has only about 200 bytes changed and/or added to patch in code for [[CDDA]] music playback.

[[Category:Games]]

Ninja Combat

2026-07-09T07:01:13Z

Furrtek:

{{GameInfo|right
|en_title=Ninja Combat
|jp_title=Ninja Combat
|jp_title2=ニンジャコンバット
|developer=Alpha Denshi Co.
|ngh_id=009
|megcount=46
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=ncombat
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-EP
|mvs_cboard=CHA-32
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_romset=ncombath
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=31/10/94
}}

Uses no custom chips.

[[Category:Games]]

NAM-1975

2026-07-09T07:01:00Z

Furrtek:

{{GameInfo|right
|en_title=NAM-1975
|jp_title=NAM-1975
|jp_title2=ナム-1975
|developer=SNK
|ngh_id=001
|megcount=46
|tcrf=https://tcrf.net/NAM-1975
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=nam1975
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-NAM
|mvs_cboard=CHA-32
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_romset=nam1975
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=09/09/94
}}

Uses no custom chips.

*C: 6 * 512kB
*P1: 512kB
*S: 128kB
*V1: 512kB
*V2: 3 * 512kB

[[Category:Games]]

Magician Lord

2026-07-09T07:00:32Z

Furrtek:

{{GameInfo|right
|en_title=Magician Lord
|jp_title=Magician Lord
|jp_title2=マジシャンロード
|developer=Alpha Denshi Co.
|ngh_id=005
|megcount=46
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=maglord
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-EP
|mvs_cboard=CHA-32
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_romset=maglordh
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=31/10/94
}}

Uses no custom chips.

[[Category:Games]]

League Bowling

2026-07-09T07:00:23Z

Furrtek:

{{GameInfo|right
|en_title=League Bowling
|jp_title=League Bowling
|jp_title2=リーグボウリング
|developer=SNK
|ngh_id=019
|megcount=26
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=lbowling
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-HERO
|mvs_cboard=CHA-32
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_romset=lbowling
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=09/09/94
}}

League bowling is one of the 3 known games supporting multi-cab [[multiplayer]].

Uses no custom chips.

==Technical features==

Does the most seizure-inducing [[palette rotation]] effect of all times on the title screen's background.

[[Category:Games]]

Ghost Pilots

2026-07-09T06:59:39Z

Furrtek:

{{GameInfo|right
|en_title=Ghost Pilots
|jp_title=Ghost Pilots
|jp_title2=ゴーストパイロット
|developer=SNK
|ngh_id=020
|megcount=55
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=gpilots
|mvs_date=1991
|mvs_pchip=
|mvs_pboard=PROG8M42
|mvs_cboard=CHA-8M
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=17/03/95
}}

Uses no custom chips.

[[Category:Games]]

Cyber-Lip

2026-07-09T06:59:31Z

Furrtek:

{{GameInfo|right
|en_title=Cyber-Lip
|jp_title=Cyber-Lip
|jp_title2=サイバーリップ
|developer=SNK
|ngh_id=010
|megcount=50
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=cyberlip
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-EP
|mvs_cboard=CHA-32
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=21/04/95
}}

Uses no custom chips.

[[Category:Games]]

Blue's Journey

2026-07-09T06:59:22Z

Furrtek:

{{GameInfo|right
|en_title=Blue's Journey
|jp_title=Raguy
|jp_title2=ラギ
|developer=Alpha Denshi Co.
|ngh_id=022
|megcount=50
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=bjourney
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG8M42
|mvs_cboard=CHA-8M
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_romset=bjourney
|aes_date=01/07/91
|cd_release=y
|cd_release_jp=y
|cd_release_en=y
|cd_date=31/10/94
}}

Platformer game with <strike>Sega Genesis</strike> colorful graphics and evil laughs.

Uses no custom chips.

[[Category:Games]]

Baseball Stars Professional

2026-07-09T06:58:50Z

Furrtek:

{{GameInfo|right
|en_title=Baseball Stars Professional
|jp_title=Baseball Stars Professional
|jp_title2=ベースボールスターズプロフェッショナル
|developer=SNK
|ngh_id=002
|megcount=50
|mvs_release=yes
|mvs_release_en=y
|mvs_release_jp=y
|mvs_romset=bstars
|mvs_date=1990
|mvs_pchip=
|mvs_pboard=PROG-EP
|mvs_cboard=CHA-32
|aes_release=y
|aes_release_jp=y
|aes_release_en=y
|aes_romset=bstarsh
|aes_date=01/07/91
|cd_release=y
|cd_relase_jp=y
|cd_release_en=y
|cd_date=21/04/95
}}

Uses no custom chips.

[[Category:Games]]

Non-PCM games

2026-07-09T06:57:54Z

Furrtek: Created page with "Early games that don't use combined ADPCM-A and ADPCM-B V ROMs (no {{Chipname|PCM}} chip): * Baseball Stars Professional * Blue's Journey * Cyber-Lip * Ghost Pilots * League Bowling * Magician Lord * NAM-1975 * Ninja Combat * Puzzled * Riding Hero * The Super Spy * Top Player's Golf =PCMization= It may be desirable to "PCM-ize" these games for converts or emulation. This is not a very simple and straighforwa..."

Early games that don't use combined [[ADPCM]]-A and ADPCM-B [[V ROM]]s (no {{Chipname|PCM}} chip):

* [[Baseball Stars Professional]]
* [[Blue's Journey]]
* [[Cyber-Lip]]
* [[Ghost Pilots]]
* [[League Bowling]]
* [[Magician Lord]]
* [[NAM-1975]]
* [[Ninja Combat]]
* [[Puzzled]]
* [[Riding Hero]]
* [[The Super Spy]]
* [[Top Player's Golf]]

=PCMization=

It may be desirable to "PCM-ize" these games for [[converts]] or emulation.

This is not a very simple and straighforward task. As countrary to PCM games which are forced to use different addresses for their ADPCM-A and B samples, non-PCM games have all the liberty to use overlapping ones since two distinct ROMs are used.

The V ROMs must be concatenated, and the sample address tables in the [[M1 ROM]] must be edited to reflect the new offsets. Because sound drivers are all slightly different, some code reverse-engineering is in order.

De-PCMization on the other hand would be easy, but rather pointless.

[[Category:Audio system]]
[[Category:Cartridge systems]]

Converts

2026-07-09T06:44:05Z

Furrtek:

[[File:boot_convert.jpg|thumb|SMT flash adapters used on a sacrificial SNK PCB.]]

In the NeoGeo community, "converts" commonly refers to modified original cartridges, having their ROMs replaced by those of another game or by programmable memory chips.

This can be done for one's own use, for selling (dubious legality if ROMs were burned), or for plain [[bootleg|fraud]].

The usual method is to replace the label on the cartridge's shell, remove the ROMs from the PCB, eventually modify the [[jumper]] configuration, and solder back either original ROMs, or freshly programmed EPROMs or flash containing the new game's data.

[[Category:Cartridge systems]]

Boot music

2026-07-09T06:30:58Z

Furrtek:

The boot music is the famous jingle played during the [[eyecatcher]] animation on system startup, and often seen again during [[attract sequence]]s.

The special [[68k/Z80 communication|sound code 2]] is used by the animation routine in the [[System ROM]] to request it. It's up to each game's [[sound driver]] code to actually play it.

Many games remap and/or add instruments (different instruments in [[Blue's Journey]], drum loop in [[Neo Bomberman]] for example), but all games seem to use the same exact melody, which was probably SNK's requirement.

[[File:Ngbootmusic.png]]

The original music is [[YM2610|FM]] only and uses all 4 channels as 2 pairs of "echo" channels (2 melodies only, each being played with a slight delay). It's played at 192 BPM and uses down to 1/32 notes.

[[Category:Audio system]]

PCM

2026-07-09T06:23:11Z

Furrtek:

{{ChipInfo
|picture=crt_pcm.jpg
|pkg=QFP80R
|manu=fujitsu
|date=1990
|gates=
|used_on=[[Cartridges]]
}}

PCM (not "'''NEO'''-PCM" for some reason) is a {{Chipname|V ROM}} address demultiplexing and data multiplexing chip, found in AES and MVS [[cartridges]], and on SNK crane game boards.

[[Non-PCM games|Early games]] had separate [[YM2610|ADPCM]]-A and ADPCM-B V ROMs. With the PCM chip, SNK devised a way to mix both types in the same ROM chip to save space and reduce costs.

The {{Chipname|NEO-PCM2}} evolution can be found in late cartridges and [[ROM-Only boards|ROM-only]] arcade boards.

=Internal logic=

The data multiplexing trick takes advantage of the predictable access relation between the ADPCM-A and APDCM-B accesses by the {{Chipname|YM2610}} (see [[YM2610 ADPCM bus]]), and a an internal timing counter clocked by {{Sig|68KCLKB|68KCLKB}}.

[[https://github.com/neogeodev/SNKVerilog/tree/master/PCM Verilog definition]].

=Pinout=

{{Pinout|PCM|640}}

*INVIN, INVOUT: Simple inverter

*SDPOE, SDROE, SDPMPX, SDRMPX: from the YM2610

*SDRAD0~SDRAD7: ADPCM-A multiplexed bus part
*SDPAD0~SDPAD7: ADPCM-B multiplexed bus part

*SDRA8, SDRA9, SDRA20~SDRA23: ADPCM-A address bus
*SDPA8~SDPA11: ADPCM-B address bus

*V D0~V D7: V ROM(s) data bus
*V A-1~V A22: V ROM(s) address bus
** When the MODE pin is low, V A19~V A22 become 4 active-low decoded outputs based on value from the internal V A19 and V A20.

[[Category:Chips]]

V ROM

2026-07-09T06:11:18Z

Furrtek: /* Speed */

[[File:v_rom.jpg|thumb|right|4MiB V ROM]]
The '''V'''(oice ?) ROMs contain the [[ADPCM]] audio samples in [[cartridges]].

In early games, the ADPCM-A and ADPCM-B data was stored in separate V ROMs. Later, the {{Chipname|PCM}} demultiplexer chip was made to allow both types of data to be mixed in the same ROM(s).

The TC5332204 mask ROMs have a similar pinout to the 27C322 EPROMs. The only difference is that they're set to byte mode only: half of the data output pins are unused. Pin 30 (Q15) is used as the address lowest bit.

==Speed==

* V A ROMs minimum speed: any will do (>2µs).
* V B ROMs minimum speed: 250ns (see [[YM2610 ADPCM bus]]).

[[Category:Chips]]
[[Category:Cartridge systems]]