CAESAR Logo

Catalogue of Arcade Emulation Software - the Absolute Reference

Valid XHTML 1.0! Valid CSS!

X-Arcade

X-Arcade

Large CAESAR Logo

namcos86.c

0.35b13 [Jimmy Hamm, Phil Stroffolino, Ernesto Corvi, Nicola Salmoria]

0.35b1 [Jimmy Hamm, Phil Stroffolino, Ernesto Corvi]


TODO:

- In wndrmomo, enemies coming out from the ground cut "holes" from the crowd in the foreground. This is because the crowd sprites have higher priority, but come earlier in the sprite list, so now that sprite/tilemap orthogonality is implemented, crowd is obscured by sprites following it, which are obscured by the tilemap. Reverting to the previous behaviour, removing orthogonality, would of course fix the problem, but I'm quite sure it wouldn't be correct.

- The two unknown writes for the MCU are probably watchdog reset and irq acknowledge, but they don't seem to work as expected. During the first few frames they are written out of order and hooking them up in the usual way causes the MCU to stop receiving interrupts.

- rthundro crashes often after you die; I've seen this happen only in area 5, though.

- Spriteram buffering fixes sprite lag, but causes a glitch in rthunder when entering a door. The *closed* door is made of tiles, but the *moving* door is made of sprites. Since sprites are delayed by 1 frame, when you enter a door there is one frame where neither the tile-based closed door nor the sprite-based moving door is shown, so it flickers. Given the experience with Baraduke, where a glitch like this is apparent in the floor 6 boss, this could very well be a bug in the original; if it isn't, I wouldn't know how to fix it. sprite-based moving door is shown, so it flickers. This behavior has been confirmed on a real PCB.

- In wndrmomo, nothing happens when setting the service mode dip switch while the game is running. This is unusual for Namco. Also, in rthunder it works during attract mode but not while playing. If you set the service switch while playing, it just hangs.

- In hopmappy, when you enter service mode the screen is flipped. Toggling the flip screen dip switch corrects the problem. It appears that some RAM is cleared after the routine that sets the screen orientation is called, while it should be cleared before. I'm not sure if this is a bug in the original, it could be a timing issue in the driver.


NOTES:

- Hardware: 1986 Namco games

- We are using an unusually high CPU interleave factor (800) to avoid hangs in rthunder. The two 6809 in this game synchronize using a semaphore at 5606/5607 (CPU1) 1606/1607 (CPU2). CPU1 clears 5606, does some quick things, and then increments 5606. While it does its quick things (which require about 40 clock cycles) it expects CPU2 to clear 5607. Raising the interleave factor to 1000 makes wndrmomo crash during attract mode. I haven't investigated on the cause.

- There are two watchdogs, one per CPU (or maybe three). Handling them separately is necessary to allow entering service mode without manually resetting in rthunder and genpeitd: only one of the CPUs stops writing to the watchdog.

- The sprite hardware buffers spriteram: the program writes the sprite list to offsets 4-9 of every 16-byte block, then at the end writes to offset 0x1ff2 of sprite RAM to signal the chip that the list is complete. The chip will copy the list from 4-9 to 10-15 and use it from there. This has not been verified on the real hardware, but it is the most logical way of doing it. Emulating this behaviour and not using an external buffer is important in rthunder: when you insert a coin, the whole sprite RAM is cleared, but 0x1ff2 is not written to. If we buffered spriteram to an external buffer, this would cause dangling sprites because the buffer would not be updated.

- spriteram buffering fixes sprite lag, but causes a glitch in rthunder when entering a door. The *closed* door is made of tiles, but the *moving* door is made of sprites. Since sprites are delayed by 1 frame, when you enter a door there is one frame where neither the tile-based closed door nor the sprite-based moving door is shown, so it flickers. This behavior has been confirmed on a real PCB.


WIP:

- 0.107u3: Brian Troha properly documented and connected the CUS60 MCU code in the System 86 driver.

- 0.93: Added clock parameter to Namco CUS30 sound (24000 Hz).

- 0.89: Nicola Salmoria updated Namco System 86 (which uses the same sprite hardware as Namcos System 1) to the latest code. Curiously, this introduces sprite/sprite priority issues in Wonder Momo. Nicola puzzled by this.

- 0.80: Nicola Salmoria understood how sprite RAM buffering works, this fixes sprite lag but causes a glitch in rthunder (which might be correct behaviour) in baraduke.c and namcos86.c

- 21st January 2003: Acho A. Tang improved sprite clipping and fixed hangs in the Namco System 86 driver.

- 22nd June 2002: Acho A. Tang fixed a few more problems in the Namco System 86 driver.

- 21st June 2002: Acho A. Tang fixed the sprite lag in Namco System 86 and System 1 drivers.

- 2nd May 2002: SUZ fixed a graphics bug in the Namco System 86 driver.

- 0.37b12: Changed VSync to 60.606060Hz.

- 0.36b7: Added Custom sound.

- 16th April 1999: Nicola and Ernesto have worked on Wondermomo and it's now fully playable.

- 15th April 1999: Ernesto Corvi has added Wondermomo to the Rolling Thunder driver but it is not yet working.

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

- 5th January 2000: Nicola Salmoria added Sky Kid DX to the Namco System 86 driver.

- 3rd January 2000: Nicola Salmoria added Hopping Mappy to the Namco System 86 driver.

- 25th October 1999: E. Watanabe fixed priority problems in Namco System 86 games.

- 0.35b13: Changed rthunder.c to namcos86.c driver.

- 19th May 1999: Nicola added two new Namco System 86 games, Genpei ToumaDen works nicely but Return of Ishtar has major problems.

- 0.35b1: Added rthunder.c driver (Jimmy Hamm, Phil Stroffolino, Ernesto Corvi).