68000 Arcade systems programming

[tryphon]

I'm looking for documentation about programamtion on 68000 based arcade systems, especially Capcom CPS-1 or Sega System 16 (in particular gfx chips).

Do you know where to find them ?

I bet mame source code is one source, but where and what to read ?

For the moment, I have that :

https://patpend.net/technical/arcade/cps1.html

[djcouchycouch]

Here's an SDK used to build games on the original Outrun hardware.

http://www.aaldert.com/outrun/sdk.html

[tryphon]

Thanks, it helps.

The topic title is maybe misleading though : I don't want to program for these boards. My goal would be closer to an emulator. So programming notes like Charles McDonald's genvdp, but for CPS-1/system16 (and I can add X68000) is closer to what I'm looking for.

[MetalliC]

I doubt you'll be able to find such notes. I'd recommend to learn MAME emulator structure.

for example CPS1:
src/mame/drivers/cps1.cpp - this is base CPS1 driver, you may find where:
void cps_state::main_map(address_map &map) - main CPU memory map
void cps_state::sub_map(address_map &map) - sound CPU memory map
MACHINE_CONFIG_START(cps_state::cps1_10MHz) - all the CPS1 hardware components
and other parts, most of them is not hard to understand if you a bit familiar with emulator development in general.

src/mame/video/cps1.cpp - video part
you may start from
WRITE16_MEMBER(cps_state::cps1_cps_a_w)
READ16_MEMBER(cps_state::cps1_cps_b_r)
WRITE16_MEMBER(cps_state::cps1_cps_b_w)
routines, which handle read/write from/to GPU registers.

[tryphon]

I guess you're right. Fortunately there are some documents describing the source code. Seems doable, though I don't speak C++ fluently

[Mask of Destiny]

They're not on his site anymore, but Charles MacDonald actually wrote docs describing various Sega Arcade boards and they are archived at various places:
Pre-System 16
System 16B
System 18
System C2
X-Board
System 24

[tryphon]

Thanks a lot, it'll be very useful.

I'm digging into MAME source code. It's really interesting. But file locations are sometimes weird. Why is the Megadrive VDP code (315_5313.cpp) in devices subdir and not in video ? Header files can be anywhere and some of them contains code...

[Tomahomae]

I found the very strange string in the KoF '94 disassembly code (taken by the MAME debugger internal disassembler):

Code: Select all

0330C4: 41FA 002C                lea     ($2c,PC) ; ($330f2), A0

What semicolon doing in the middle of instruction I quoted previously, before second operand designation? Is this code string auto-commented, or something else?

[Sik]

Oof, I'm guessing that comment should have been after a0, not before (I haven't looked but I'm guessing the address there is where $2C(pc) actually points).

[Tomahomae]

But what is command bmi is?

Code: Select all

0330CE: 6B20                     bmi     $330f0

I have never find such command in any M68k ASM guide I used.

[Chilly Willy]

Really? It's under "Bcc" and it's branch on minus (if the N flag is set).

[Sik]

I'm assuming Tomahomae wasn't referring to the programmer manual (and yeah, some of the branch options often are skipped).

BPL = branch if plus (if result is positive)
BMI = branch if minus (if result is negative)

They don't fall under the obvious comparison stuff (=, ≠, <, >, ≤, ≥) so I can see how guides may glance over them, but they're extremely useful in practice, especially after a MOVE or TST (as it's basically a faster way to check the MSB).

[Chilly Willy]

Quite right. EQ and MI give a quick way to discern three states for any integer - zero, positive (and not zero), and negative. That's often enough for many flags without needing an actual comparison against constants. Of course, the 6502 BIT instruction was even more handy as it gave you instant checks on both bit7 and bit6, as well as zero/non-zero. I used that quite a bit back on my old Atari.

[Tomahomae]

You can keep an eye on KoF '94 disassembly reverse engineering process here. Maybe, many potential arcade romhackers would be able to find something interesting and useful for themselves there.

[Tomahomae]

Not so long time ago I disassembled Riot City (System 16) using internal disassembler of MAME debugger. But there is a some strange thing in main CPU program code rom disassembly - it remains a real code at least a little bit at the separate sections (003154~0034DE, 0035E2~0036C6, 0037CA~003C78, etc.) only, and noticeable its part is a giant "walls" of ori.b #$x, D0 commands at the beginning, nops in the middle, and move.l -(A0), D0 or dc.w $ffxx; opcode 1111 command at the end.

I hope, the disassemblation passed correctly, I choosed the right memory sections, and there is no undecrypted code left?