68000 Assembly Programming for the NeoGeo

The SNK NeoGeo always had "mythical" status during my childhood... everyone knew what one was, but it was so out of the price-range of what we could hope to get it was never really on our radar. The NeoGeo was a simple concept, using the exact same hardware as an arcade, with just some technical tweaks to make it more suited for home users... (and unfortunately the same cost!)... the Neo Geo gave the wealthy the ability to have all the power of high-end arcade hardware at home.. Now that the NeoGeo is easily emulatable, we can all run - and develop for - this hardware at home!

Specs: Neo GEO AES Cpu 12mhz 68000 Ram 64k Cart ROM 2MB Graphics ROM 16MB  sprites + 128K Fix Tiles (Font) Vram 64K + 4K Resolution 320x224 (288x208 visible) - 4096 colors onscreen Sprites 380 sprites of size 16x16-16x512 - (96 per line - 380 onscreen) Bitmap planes NONE! Colors 16 per 16x16 sprite - 256 x 16 color palettes from 65536 Sprites 380 sprites onscreen 16 color  (16x16 px 32 per line) (max 96 per line) Can be chained to make larger sprites Suport X and Y scaling (Down only) Sound chip 6mhz Z80 compatible (84C00AM-6) sound CPU YM2610 + ADPCM Power Supply 5V  3A 9V 1.5A (depending on model)  Center pin NEGATIVE

ChibiAkumas Tutorials

Most Console systems will have 2 types of graphics layer... a 'Tile Map' which is a grid of predefined 'tiles'... these are usually 8x8 in size... on a 16 bit system, usually multiple layers of tilemaps exist to define paralax... On top of this we would add sprites to make our player character and other such things... But the NeoGeo HAS NO TILEMAP!

So how does the NeoGeo work with no Tilemap? Well... sprites on the NeoGeo are 16 pixels wide, and can be up to 512 pixels tall - but they can be combined!... and because the NeoGeo is capable of a whopping 380 tiles, we can combine 20 of them together to 'simulate' a tilemap!... this is how background graphics are drawn on the Neogeo! On top of this are our 'normal' sprites - enemies, player characters and such... There is one final layer, the 'Fix Layer'... this is made up of 16 color 8x8 tiles, in a simple grid... it's designed to do onscreen text and the like... but I used it in GrimeZ80 to do all the game graphics... so if your needs are simple, and you want 8x8 block graphics, it can be used for the job... but don't worry, we'll learn about sprites later!

The Neogeo screen has a resolution of 320x224, and each tile is 8x8 - giving an effective screen size of 40x28... The actual tilemap is 40x32... the top and bottom two lines are not show (Shown in red on the chart to the right) However, because of the CRT layout - it is likely that the left and rightmost 1 column will not be visible (Shown in orange to the right)... this gives a visible screen of 38x28 The Fix Layer is positioned in VRAM at &7000 (each position contains 1 word / 2 bytes)- each Tile is defined by 16 bits in the following format: F E D C B A 7 8   7 6 5 4 3 2 1 0 P P P P T T T T T T T T T T T T Where P is the Palette number, and T is the Tile number The fixmap appears at $7000 in Vram... tile data for the Fixmap are in ROM Tiles in memory are ordered in COLUMNS... so in memory (X,Y) co-ordinate (0,1) comes after (0,0) ($7000)... and (1,0) comes 32 words  ($7020) after (0,0) For example - to set tile (0,2) to tile 256 in palette 1 (note this is in the "May be offscreen" area, but should appear on an emulator)     Move.W  #$7002,d1        ;Address - Tile 2     Move.W  #$1100,d0        ;PTTT    - Palette and tile     Move.w d1,$3C0000       ;set address in vdp     Move.w d0,$3C0002       ;set tile data in vdp
Fix Layer tiles are in an odd format! Each tile is 8x8 at 4bpp ... so 32 bytes per tile... The two nibbles of each byte represent 2 pixels , but they are BACKWARDS... so the 1st (High) nibble is the 2nd pixel color, and the 2nd nibble (Low) is the 1st pixel color The bytes are stored in Columns, then rows... and the columns are out of order too! .. Visible pixels ABCDEFGH are stored in Ram in order FEHGBADC The 8 bytes of each column are in normal top->bottom format... so at least that:s something!
My AkuSprite editor (used in these tutorials) has support to export images in the correct "Fix" format for the NeoGeo

MAME NeoGeo Rom XMLs

To run a custom game on MAME, we need to create a hash file - usually called 'neogeo.xml' This defines how the various binary files that make up a game are attached to the system... multiple files can be combined for a single purpose - the 'Offset' Section NAME  Detail How to make this? maincpu 68000 binary data compile a 68000 ASM file with VASM fixed FIX Layer Tiles My AkuSprite Editor can make this format audiocpu Z80 binary data compile a z80 ASM file with VASM sprites Sprite pattern data My AkuSprite Editor can make this format
There are various parameters for 'rom' files that must correct for MAME to be happy, otherwise you will get the error "One or more ROMs/CHDs for this machine are incorrect. The machine may not run correctly"... To fix this you must ensure the following parameters are correct: parameter name Detail code used by my MakeNeoGeoHash.exe size File size in bytes (0x denotes it's in HEX) %size% crc Cyclic Redundancy Check (32 bit) of file %crc% sha1 sha1 of file %sha%
If you want to calculate the hashes, you can do so with my 'MakeNeoGeoHash' program - you need to provide it a template (shown to the right) - it will calculate the size,crc and sha1 of each rom, and write out a new xml which mame will be happy with! MakeNeoGeoHash is included in my 68000 development tools package, with scripts to use it automatically with my tutorials samples

Memory Map

The FM chip uses 2 pairs of ports, $04 and $06 select the address of the register we want to change, $05 and $07 write the new data, but after each write, we need to check if the FM chip is busy,
To check if the FM chip is busy, read in from port $04, and check bit 7 - it will return 0 when not busy.

The NeoGeo sound chip is backwards compatible with the AY... and cannot be accessed by the 68000, so we have to get the Z80 CPU to do the sound work... The Z80 has its own program code contained in a ROM and separate memory - and we have to pass data betrween the Z80 and 68000 with a single byte RW port! Writes to Z80 port &0C can be read from 68000 port $320000 , and writes to 68000 port $32000 can be read from port &00

Sound Ports
Communication between the Z80 and 68000 work with the following ports

FM Algorithm (&B1/B2)
The algorithm number is one of 8 - each one defines how the different operations build up to build a sound:

FM Sound over time
The sound created is affected over time by the various registers, we can see a simple representation below:

Z80 Sound Commands

The YM1610 is backwards compatible with the AY-3-8910 - we covered using this chip in the Z80 Tutorials here!

On the NeoGeo Sprites are 16 pixels wide, and are made up of tiles 16 pixels tall... they are 16 colors (4 bitplanes) so each tile is 128 bytes... The NeoGeo is capable of up to 380 sprites total. A sprite can be made up of up to 32 tiles to make the sprite taller... there is also a 'Chain' bit - this will connect a sprite to the previous sprite (Sharing its position) to make a sprite wider! Hardware sprite Tiles are not in the same format as the FIX layer - they are 16x16 pixels in size and use bitplanes, but the layout is odd, and they are split onto two rom files (C1/C2 or C3/C4 etc) The sprite is split into 2x 8 pixel wide 'columns' the rightmost one is stored first - each pair of bitplanes 0 & 1 are stored together in ROM C1 - and 2 & 3 are stores in ROM C2 - all 16 lines of the right half are stored first - then the 16 lines of the left side are stored - making a total of 128 bytes (64 in each file)

Valid Tile Counts (T) are 1-12 , 32 and 33 (13-31 are invalid)
A special Tile Height of 33 makes the sprite the Full height of screen - use for building a 'tilemap'

Note: Tile number $2000 would be loaded at ROM address 0x100000 in the XML

First we write the Address of the Sprite Attribute we want to change to $3C0000, then we write the new word value for the address to $3C0002

If you want to AutoInc the VRAM destination after each write, write 1 to $3C0004 or 0 to turn it off.

To the right is the source of a working example for showing a 32x32 sprite! (made up of 2 chained sprites of 2 tiles each) In MAME We need to load our sprites into the $10000 area for this to work - a working XML is shown below: <dataarea name="sprites" size="0x400000">   <rom loadflag="load16_byte" name="202-c1.c1" offset="0x000000" size="0x100000" crc="479543cf" sha1="772690c872632320133a799aa41f6e68a8d07a4c" />   <rom loadflag="load16_byte" name="202-c2.c2" offset="0x000001" size="0x100000" crc="1f6431d5" sha1="7c90d6ec9df9e6223a066c338b7a7886071370cf" />   <rom loadflag="load16_byte" name="Sprites.c1" offset="0x100000" size="0x100000" crc="479543cf" sha1="772690c872632320133a799aa41f6e68a8d07a4c" />   <rom loadflag="load16_byte" name="Sprites.c2" offset="0x100001" size="0x100000" crc="1f6431d5" sha1="7c90d6ec9df9e6223a066c338b7a7886071370cf" /> </dataarea> Note... Mame will sulk (immediately close) unless the file size of all these sprites are exactly 1MB each (1,048,576 bytes)

;$3C0000=Select VRAM Address ;$3C0002=Send data to VRAM     move.w #$0040,$3C0000         ;Show Tile 0 from bank $100000     move.w #$2000,$3C0002        ;NNNNNNNN Tile - my tiles start at $2000         move.w #$0041,$3C0000         ;Use Palette 1     move.w #$0100,$3C0002        ;PPPPPPPP NNNNAAVH Palette Tile, Autoanimate Flip         move.w #$0040+2,$3C0000     ;Show Tile 1 from bank $100000     move.w #$2001,$3C0002        ;NNNNNNNN Tile         move.w #$0041+2,$3C0000     ;Use Palette 1     move.w #$0100,$3C0002        ;PPPPPPPP NNNNAAVH Palette Tile, Autoanimate Flip         move.w #$8000+1,$3C0000     ;Full size     move.w #$0FFF,$3C0002        ;----HHHH VVVVVVVV - Shrink         move.w #$8200+1,$3C0000     ;Top of screen - 2 tiles tall     move.w #$F402,$3C0002        ;YYYYYYYY YCSSSSSS Ypos - Chain Sprite Size         move.w #$8400+1,$3C0000     ;Left of screen     move.w #$0800,$3C0002        ;XXXXXXXX X------- Xpos      ;Sprite 2        move.w #$0080,$3C0000         ;Show Tile 2 from bank $100000     move.w #$2002,$3C0002        ;NNNNNNNN Tile - my tiles start at $2000         move.w #$0081,$3C0000         ;Use Palette 1     move.w #$0100,$3C0002        ;PPPPPPPP NNNNAAVH Palette Tile, Autoanimate Flip         move.w #$0080+2,$3C0000     ;Show Tile 3 from bank $100000     move.w #$2003,$3C0002        ;NNNNNNNN Tile         move.w #$0081+2,$3C0000     ;Use Palette 1     move.w #$0100,$3C0002        ;PPPPPPPP NNNNAAVH Palette Tile, Autoanimate Flip             move.w #$8000+2,$3C0000     ;Full size     move.w #$0FFF,$3C0002        ;----HHHH VVVVVVVV - Shrink         move.w #$8200+2,$3C0000     ;Chain Sprite - Ypos ignored     move.w #$0040,$3C0002        ;YYYYYYYY YCSSSSSS Ypos - Chain Sprite Size         move.w #$8400+2,$3C0000     ;Xpos ignored due to Chain     move.w #$0000,$3C0002        ;XXXXXXXX X------- Xpos

If you're shrinking sprites, and it's causing 'glitches' in the transparent areas of the sprite (black animated dots) try setting the other tiles of the sprite to a transparent pattern (even if they shouldn't be used) - It seems to fix the issue!