misc (nw)

This commit is contained in:
David Haywood 2016-04-19 16:06:52 +01:00
parent c97e2cb590
commit 3bf4db88b8
3 changed files with 27 additions and 4 deletions

View File

@ -19,6 +19,11 @@
Snow Board | 1996 | CG-1V 366 | 960419/1 | Lattice IspLSI 1016-80LJ
Bang! | 1998 | CG-1V 388 | 980921/1 | No
Notes:
touchgok:
sounds cut out sometimes, others are often missing (sound status reads as busy,
so no attempt made to play new sound) probably bug in devices\sound\gaelco.cpp ??
***************************************************************************/
#include "emu.h"
@ -1517,7 +1522,7 @@ GAME( 1994, aligatorun,aligator,alighunt, alighunt, gaelco2_state, alighunt, ROT
GAME( 1995, touchgo, 0, touchgo, touchgo, gaelco2_state, touchgop, ROT0, "Gaelco", "Touch & Go (World)", MACHINE_UNEMULATED_PROTECTION | MACHINE_NOT_WORKING )
GAME( 1995, touchgon, touchgo, touchgo, touchgo, gaelco2_state, touchgop, ROT0, "Gaelco", "Touch & Go (Non North America)", MACHINE_UNEMULATED_PROTECTION | MACHINE_NOT_WORKING )
GAME( 1995, touchgoe, touchgo, touchgo, touchgo, gaelco2_state, touchgop, ROT0, "Gaelco", "Touch & Go (earlier revision)", MACHINE_UNEMULATED_PROTECTION | MACHINE_NOT_WORKING )
GAME( 1995, touchgok, touchgo, touchgo, touchgo, gaelco2_state, touchgo, ROT0, "Gaelco", "Touch & Go (Korea, unprotected)", MACHINE_IMPERFECT_GRAPHICS )
GAME( 1995, touchgok, touchgo, touchgo, touchgo, gaelco2_state, touchgo, ROT0, "Gaelco", "Touch & Go (Korea, unprotected)", MACHINE_IMPERFECT_SOUND ) // doesn't say 'Korea' but was sourced there, shows 2 copyright lines like the 'earlier revision'
GAME( 1995, wrally2, 0, wrally2, wrally2, driver_device, 0, ROT0, "Gaelco", "World Rally 2: Twin Racing", MACHINE_UNEMULATED_PROTECTION | MACHINE_NOT_WORKING )

View File

@ -7360,7 +7360,7 @@ ROM_START( kamikazp )
ROM_LOAD( "KK7PMC.bin", 0x0800, 0x0800, CRC(58673a07) SHA1(4e51f803718f39436e43d3bceda836215a98cc37) )
ROM_REGION( 0x0020, "proms", 0 )
ROM_LOAD( "prom.6l", 0x0000, 0x0020, CRC(6a0c7d87) SHA1(140335d85c67c75b65689d4e76d29863c209cf32) ) // not dumped, taken from Astrians, colours match screenshots
ROM_LOAD( "prom.6l", 0x0000, 0x0020, CRC(6a0c7d87) SHA1(140335d85c67c75b65689d4e76d29863c209cf32) )
ROM_END
ROM_START( superg )

View File

@ -709,8 +709,26 @@ Pixel clock is 16MHz, hsync is every 656 pixels, cpu clock is 10MHz.
So that's 656*10/16=410 cpu clocks per hsync, or 410*512=209902 total.
With 26 cycles per loop, that's 8073 loops. Freeplay it is.
So, now what? Maybe the cpu is 8Mhz, maybe there's a wait time on the
a00000 access.
--- Update from Charles MacDonald ---
I ran some tests. For the two CPUs, A (68000) and B (FD1094), normally
there are no wait states when CPU A accesses $A00000. As that address
is on CPU A's bus, CPU B's accesses to it take twice as long (eight 10 MHz
clocks instead of four) due to contention. The only exception is when
CPU A is completely idle from a STOP instruction, at which point CPU B
can access that memory at full speed (four clocks per access).
Assuming Gain Ground has CPU A running code out of BIOS ROM or work RAM,
and CPU B is running out of work RAM, then each one of those $A00000
accesses will eat up double the time.
The other factor is DRAM refresh for the work RAM, both CPUs have some
memory access stretched out by four cycles every 19 to 20 ms. It looks
like both DRAM banks are refreshed in parallel which seems to explain
why refresh on CPU A's bus doesn't count as contention for CPU B and
vice-versa. So there's only refresh event that eats up time for both
CPUs to worry about.
*/